From: heggers@netcom.com (Henry Eggers) Subject: Re: Free *Ick Project (Pronunciation and Documentation request) Date: 1996/03/04 Message-ID: #1/1 sender: heggers@netcom13.netcom.com references: <4hd7bo$mbj@girtab.usc.edu> organization: NETCOM On-line Communication Services (408 261-4700 guest) newsgroups: comp.databases.pick Robert Doiel (doiel@girtab.usc.edu) wrote: : ...Right now I am looking for a formal description the Pick : Basic Language. For lack of a better standard I am looking at : shooting at something which is SMA compliant (unless there are better : suggestions). If anyone has pointers to the SMA spec I would very : much appreciate it. Doubting that that SMA:1.01, 'all about Basic' is rotating, I observe that it was the first of the SMA standards, and is therefore most fraught with the inter-corporate paranoia of the mid-'80's: No one was opening the kimono the slightest bit. The result is that the basic 'definition' is the syntax of the minimum common set of operators, functions and statements, with _no_ indication of what any of them do. All they have to do is compile. So, if you're looking at a 'basic to java' compiler, of which I note in passing that I approve, I would recommend going after the 'center'. First, you are going to need to deal with the 'data-typing' -- not -- of pick basic, probably with a public class DynamicArray extends Object (since it can't extend String, because string is a 'final class', so you also won't have any pesky inheritance to worry about). So you probably need input, print, open, read, write, the data language intrinsics, and a 'view' of arithmetic on strings... Actually, one might suggest a class TypedData, to allow the conflation of everything with everything else: strongly typed chaos. Rather appeals, on reflection... Let me consider this a moment further: TypedData, then, would include the _descriptor_ for each variable, including its type and the 'name' of the instance in it's 'current instantiation' type. And you would then, by virtue of an n-type switch statement in each 'member function' of TypedDayta, which invokes the relevant function in the underlying type... The point here is to implement something which completely subverts the premise of compile-time typing. Hmmmmm... could be fun. heh heh. If you can use lex and yak, bison and flex (or whatever) to 'compile' (most) pick code into something, which can then emit java source, and then be java compiled (rather than going directly to the bytecode, but maybe that's 'cause I know more about the source than the byte code). Your first two challenges are to compare a string of length 1 to a character, and to turn a string (of numeric digits) into an integer. And, for a really good time, open a file using the modal browse dialog box... So: Deal with the data structures and fundamental housekeeping/survival, and the surface operations will follow by crank turnage. : encumbered so I don't have to rewrite all the documentation on my own What documentation? This thing was never documented. We don't need no stinken' documentation. If it needs documentation, it's not intuitive enough. Perhaps a list of the monsters and their attributes... All you need to know is that the data is kept as a sparse three-dimensional array, with extractors and inserters. It might be 'useful' to leave the toString() representation as appearing to include delimiters, but by the nature of OO/Java, what you really do is up for grabs. Go for it. The snidity above is for pick and java, not for your idea. Actually, pick and java have a lot in common, as to documentation, function, concission, funkadelicity... Regards, hve.