On Tue, 18 Sep 2001, Guido van Rossum wrote:
> > Here is the third draft of what a middleground for programming languages
> > would be (according to me). This version includes the type-system layer,
> > corrections to the character layer, a small part of the remote-call layer,
> > and improved introduction.
> > Thanks for your attention and feedback, or lack thereof.
> > http://hostname.2y.net/~matju/LGram/LGram-0.7.pre3.txt
> It might be clearer if you said upfront what this is -- a data
> exchange language.
Oops, I'm sorry for my communications skills, or lack thereof. The above
was a butchered version of the LGram draft 1 announcement, which by itself
was not good. Here's the intro paragraph I've written about LGram on my
web page:
A project for a universal computer-communication language. It
differs from XML in that it has no attributes and no tags and
isn't about marking up text. Instead, nested lists are used to
denote objects (basic elements being strings, integers, symbols,
etc). A lot of attention is put in describing usages of that
language within the language itself, so that you don't need
separate "document-type definition" (DTD) nor "interface
description" (IDL) languages to do that.
which is probably much more useful as an introduction.
> I'd appreciate if you added Python to your list of targets.
ok, i added this note to the spec:
--------
note: conditions for adding to the list of supported languages is:
* someone must be willing to ensure proper supporting elements
get introduced into the specification (if necessary)
* someone must be willing to write and maintain an implementation
of LGRAM
--------
So are you willing to write and maintain "LGRAM for Python" ?
> Note that Python doesn't have true and false (they's
> indistinguishable from 0 and 1 except by context),
Of the five languages on the list, only Ruby has true and false anyway, so
you are not alone.
The solution I've thought about is that runtime type-checking may double
as a coercion/conversion mechanism. This could be sufficient at level
#3/#4 when there are sufficient amounts of type-checking.
There is some difficulty at level #2 though, because if I make an object
called "false" that plays the role of a false value within the framework
of LGRAM, and then i pick up such a value and try to use it, the language
may not have the flexibility required to consider such a thing as a false
value. I don't know whether I can really solve this though.
> and its None behaves different from your nil -- e.g. the list [None]
> is not the same as the value None.
The list [None] is written (Array (nil)) and the value none is written
just (nil), and they are not considered equal.
at level #1, (nil) is a list because it has parentheses, but at level #2,
it is just nil or None or undef or NULL or whatever; that is because the
constructor table says nil means that.
LGRAM may look somewhat like CommonLISP or Scheme, but is *not* close,
especially in semantics.
In LGRAM, only 4 kinds of data need not parentheses; writing down a symbol
does not pick up a value in a symbol table, because LGRAM does not
evaluate anything past the first element of a list. So if you write just
nil, that will be a symbol called nil, and not anything else.
OTOH, for every list, there's a call to a function in a "constructor
table"; if you write (nil) and there's a constructor called nil, then you
have a chance of getting something else than "elementary" data (nil is not
considered elementary).
________________________________________________________________
Mathieu Bouchard http://hostname.2y.net/~matju
