GNU Extension Language Plans

[Guillermo J. Rozas <gjr@martigny.ai.mit.edu>]

|   Mime-Version: 1.0
|   Content-Type: text/plain; charset="us-ascii"
|   Date: Mon, 24 Oct 1994 11:22:20 -0800
|   From: KenD@Newton.apple.com (Ken Dickey)
|
|   This can be supported with a simple mapping strategy to cannonical case
|   with an alternate reader/printer. E.g. GEL: 'WhereIsCaseSensitive? <->
|   Scheme: '~where~is~case~sensitive?

Why does this matter?  I am one of those people who think, in the
abstract, that case sensitive names are a mistake, but I don't think
that it is a big deal to have implementations where symbols differ in
case.  Given the large amount of elisp code out there (elisp is
case-sensitive) that will presumably be translated/macro-expanded into
GEL, it is perfectly reasonable for him to make this decision.

|   >** No distinction between #f and (), for the sake of supporting Lisp
|   >   as well as Scheme.
|
|   In a compiled environment the alternate code sequence is essentially the
|   same.   One can arrange that the check for (or '() #f) is pretty cheap by
|   setting up the tags appropriately.  This could be expensive in an
|   interpreter.  I think that any additional cost of the extra check should be
|   borne by the Lisp-in-Scheme runtime.

I think it is a little harder than that.  EQ also makes this
schizophrenia visible, and hence every single predicate in the
language (e.g. what does < return?).

The best solution to this problem that I have seen so far is what
Stephen Adams implemented for the new in-house version of MIT Scheme.

The (new) MIT Scheme images are built with distinct '() and '#f
objects, but on startup, if an appropriate command line argument is
present, the system unifies both values so that only one of them ('#f)
is present in the running image, and only one will be generated by any
executed code, which references them from standard registers.  This
unification is also performned on any loaded binary code and data.
Thus you can have a system that works either way, although pervasively
for any given session.

|   I think that some input on a module system would help here.  I do *not*
|   favor separation of namespaces {one of Common Lisp's real lossages in MHO,
|   another being Packages}.  I am not sure that I want to rule out
|   implementations which use tables and "pure" symbols rather than adding
|   slots to symbols.  This is one place where I would like to see a real
|   discussion of the issues.

Packages have nothing to do with separation of namespaces and are
rather innocuous.  There is still a single namespace.  Packages are
largely a lexical convention involving prefixes, and a defaulting
convention for not having to type them every time.

|   >** Access to all or most of the Unix system calls.
|   >** Convenient facilities for forking pipelines,
|   >   making redirections, and so on.
|
|   I think that this should be done in the context of a foreign function and
|   data interface.  As Unix is losing market share, we don't want to preclude
|   support for other OS's.

We?  The FSF is primarily (almost exclusively) interested in a Unix
variant, namely GNU.  Anything outside that path is of very low
priority.

I think people are taking this _far_ too negatively.  I welcome
Richard and the FSF into the Scheme community.  

I don't look with apprehension at the possible (and quite likely)
situation that GEL will become the de-facto Scheme standard.  We have
not succeeded in giving wide exposure to Scheme.  If he does, and he
has to change (or prefers to change) a few not-terribly-significant
aspects to accomplish this, more power to him.