On 6/21/2006 at 11:43 AM Don Y wrote: Back in the 60's and 70's there was a brief interest in "natural" programming languages that used English as a basis. The goal was to provide something that would be easy for an "average" person to use. As I recall, one used only a period (in many cases optional) and hyphen as punctuation. E.G; "Take the 50-th element of dog and multiply it by cat giving hamster. or some such. Not too far from COBOL, except that there was no reserved meaning attached to asterisks, plus and minus signs, etc. And, as far as each statement began with a reserved imperative verb, the period (full stop) was optional. Some special-purpose languages are fairly light on punctuation (e.g. RPG, GPSS). I suspect that there are a quite a few old fixed-field syntax languages out there that probably use no punctuation at all. Then, there are languages that are seemingly ALL punctuation, like APL. But, in fact, this is a largely artificial distinction. Most punctuation is simply abbreviation. C uses "{}" for the same thing that other languages use "BEGIN" and "END". One can use an asterisk to acomplish the same thing that MULTIPLY accomplishes in COBOL. I find it more interesting that the punctuators are at a definite disadvantage in that there is a limited set of punctuation characters that rarely cover all of the needed uses, meaning that overloading or di- and trigraphs are necessary. Sometimes, even this is hopeless. COBOL has no punctuation equivalent for "MOVE CORRESPONDING" or "EXAMINE", for example. Cheers, Chuck

Chuck wrote... Well, it wasn't a programming language, but it was a command prompt data retrieval database language. Pick (aka Reality, Sequel, Zebra, Revelation, Mentor, Ultimate, Prime Information yada yada yada....) did. For example, at the command prompt, the following are valid commands and yield just what you'd think. LIST CUSTOMER-INVOICES WITH ORDER.AMOUNT > "50.00" SELECT CUSTOMERS WITH ZIP = "63102" AND WITH AR.BALANCE # "0.00" LIST CUSTOMERS NAME ADDRESS CONTACT And of course you could store those commands in a file and even use in-line prompting for variables, so it was kind of a programming language too. Jay West

Bryan wrote.... In "standard" pick the Data Retrieval "language" I gave examples of was called "Access". Microdata/McDonnel Douglass platforms called it "English". I believe Universe/Unidata (the unix pick variants) called it "Revise". Notably absent on most implementations was any way to update the database. It was strictly for reporting/retrieval. Pick's predecessor/initial design (sort of) was a military funded project called "GIRLS", Generalized Information Retrieval Language System (or something to that effect). It's project definition was to create a database retrieval language that used common spoken style english and required no training to get information out of the syste. This was somewhere around the mid to late 60's I think. I doubt anyone looked at this when creating SQL, Pick's following has always been both fanatical and small. Jay

Jim wrote.... Codd: Going from VERY foggy memory here, but I do remember personally taking the Codd rules/tests and applying/satisfying them one at a time with Pick. Pick did meet the Codd published rules for being considered a relational database. But did Codd people look at Pick is the question - on that, I have no clue, but I'd be suprised. Multivalues - that right there is the magic of Pick. Not just that they supported it, but how artfully & easily they supported it because of the design. That's what made Pick phenominal. Jay West

Cameron wrote... The best documentation on the Pick virtual machine - bar none - is "The Rainbow Book" as it is commonly referred to because of the front cover graphics (but that's not the name). The actual book is the "Reality by Microdata Assembly Language Reference Manual". It's the only book that really describes the guts. I believe I gave a copy to Al for bitsavers. In addition to that, I have probably about thirty plus (3 inch thick each) field engineer and internal only microdata binders. Awesome stuff :) Those will make it to bitsavers someday. With regards to the Pick Language, that's kinda hard. The beauty of Pick was the really tight melding between the virtual assembler, basic, and the database. You really can't appreciate one of them separately. It's only when you see how tightly integrated all 3 were that the beauty of the design becomes apparent. In most versions of basic, one must go through gyrations to do any serious database work (at least, what appears to be gyrations to pick-ites). In most basics, working with the filesystem feels like wearing mittens. With Pick BASIC, database I/O is almost relegated to the background of the programmers mind. That is also why Pick claims (and delivers) such rapid application development timeframes. Because programmers can write serious business applications so very quickly compared to most other systems - largely due to the way pick basic works with file I/O. Jay

On 6/21/2006 at 2:34 PM jim stephens wrote: Aren't most database query languages fairly punctuation-poor when compared to general-purpose programming languages? I'm thinking of one of early examples--MEDLARS. I seem to recall very little punctuation in the query language used there. Cheers, Chuck

Chuck Guzis wrote: That depends. For example, SQL requires a terminating semicolon. And, uses parens in many cases. Plus commas, etc. And, of course, any expressional notation uses typical punctuation. For example: SELECT book, author FROM titles WHERE isbn_publisher(book) > isbn_publisher('1-234-56789-X'::isbn); Plus, the "programming language" variants of those "query languages" are almost as punctuation-rich as typical languages.

Jay West wrote: So, how would you implement this example? SELECT book, author FROM titles WHERE isbn_publisher(book) > isbn_publisher('1-234-56789-X'::isbn); Specifically: - return the values of the "book" and "author" fields - from the "titles" table - for those records in which the "isbn_publisher()" [1] function returns a value that exceeds that of the isbn_publisher()'s value for the isbn data type [2] corresponding to the string representation "1-234-56789-X" [1] defined a returning the value of the Publisher Identifier in the ISBN argument -- "234" in the second instance, here [2] the "::isbn" is an explicit type cast in this case from a string to an "isbn"

Jay West wrote: ISBN's have four parts: Group Identifier, Publisher ID, Title ID and Check Digit. Check Digit is redundant -- if you have the other three parts, you can derive (verify!) the Check DIgit. Parts are separated by hyphens. Or spaces (but not a mixture thereof). Always 9 digits [1] -- plus the check digit (which may be an 'X' as it is computed modulo 11 -- X == 10). But, the pisser is that the positions of the hyphens vary as a function of the 9 digit "value" represented. I.e. for a particular value, the hyphens (or spaces) *must* be in certain positions (though the third one always precedes the check digit). As expected, the first set of digits before the first hyphen is the Group ID; the second set of digits is the Publisher ID; and the third set is the Title ID. Some examples: 0-10-337439-6 1-234-56788-1 1-234-56789-X 1 234 56790 3 1-55529-512-6 9953-26-719-1 Some *bad* values: 01-0-337439-6 (incorrect hyphenation) 1-234-5678-8-1 (wrong number of hyphens) 1-234-5678-3 (wrong number of digits) 1 234 56790-3 (can't mix spaces and hyphens) 1-55529-512-7 (check digit is incorrect) 9976-990-00-6 (this number just hasn't been allocated yet) The point of all this is that ISBN's aren't "just numbers". Though one could chose to *represent* them as numbers (a long/int32 works well). And, that ISBN's have information contained *within* them (heh heh heh... don't you just LOVE all this SURPLUS PUNCTUATION i stick in my comments?? :> ) like the ID of the publisher, etc. So, you want to be able to extract that information from a particular (valid) ISBN: isbn_group(isbn) returns the group ID of the isbn argument isbn_publisher(isbn) returns the publisher ID of the argument isbn_title(isbn) returns the title ID of the argument isbn_check_digit(isbn) returns the check digit Publisher ID's are only significant within a particular Group ID. I.e. publisher 234 in group 1 is not the same entity as publisher 234 in group 0. Likewise, title ID's are only significant within a particular (group,publisher) pair. Obviously, title 56789 for (group,publisher) of (1,234) is not the same as for (0,234) or (1,235)! [clearly different ISBN's so different "books"] Given that, you might want to do a query to identify all other titles by the same publisher as some particular book that you happen to have: SELECT book, name_of_book FROM titles WHERE isbn_group(book) = isbn_group('1-234-56789-X'::isbn) & isbn_publisher(book) = isbn_publisher('1-234-56789-X'::isbn) ; I.e. find books whose's publisher identifier agrees with the publisher ID in '1-234-56789-X' (that is, '234') and whose group ID also agrees (that is, '1') -- since a publisher is only known to be "the same" if he is in the same group. This has drifted further off topic :-( But, it was intended to show how cluttered with punctuation this query became for something "easy". Consider how I might ask "What is the title of the book having the ISBN immediately *after* this one?": SELECT book, name_of_book FROM titles WHERE book = isbn_build( isbn_group('1-234-56789-X'::isbn) , isbn_publisher('1-234-56789-X'::isbn) , isbn_title('1-234-56789-X'::isbn) + 1 ); [2] given: isbn isbn_build(int groupID, int pubID, int titleID) So, how would you extract this information from the "book" datum in pick? Presumably, with some sort of user defined operator? Or, would you have to split the ISBN into 3 different fields (group, publisher, title) and store it that way so you could manipulate each independantly? [remember, what we're discussing is the role of PUNCTUATION!] Ah, OK. Like REXX, etc.? That seems to suggest that you would have to split the ISBN into its component parts in order to be able to manipulate those parts. I.e. you couldn't just "add one" to "1-234-56789-X"? I really find it hard to figure out how to do away with parens/braces/etc. They just have too big a role in The Way We Do Things. :-( But, for those "non symbol manipulators", they really are not very intuitive! [1] ISBN is now being augmented by ISBN-13 [2] Technically, I would have to make sure isbn_title()+1 did not exceed the maximum title ID for that (group,publisher) -- which varies with the (group,publisher)!

That's what I thought too. I've seen select x, y, z from pdq order by abc go in some DBs. -- --------------------------------- personal: http://www.armory.com/~spectre/ --- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser at floodgap.com -- Advertising is the banging of a stick in a swillbucket. -- George Orwell ---

On 6/22/06 3:49 PM, Sridhar Ayengar wrote: True. It is also not consistent across implementations: in DB2-SQL, it is used merely to separate statements and optional at the end of single statement, while in NonStop-SQL it is mandatory to end each statement with a semicolon. Unclosed statements are interpreted as incomplete. ,xtG .tsooJ -- Judge a man by his questions rather than by his answers. - Voltaire -- Joost van de Griek <http://www.jvdg.net/>

Sridhar Ayengar wrote: Yes, implementations that allow newlines within the query. (living without newlines is like bread without butter! :> )