[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GNU Extension Language Plans



At  8:28 AM 10/24/94 -0400, John D. Ramsdell wrote:
>As you all probably know, Richard Stallman announced plans to base a
>GNU Extension Language on Scheme.  For the purposes of this note, let
>me call the language GEL, because the language is supposed to be used
>as glue to join various parts of an application.  Scheme programs that
>distinquish between #f and (), and those that use the fact that symbol
>names are case insensitive will not have an obvious translation into
>GEL, but all others will.  Given the broad support for Scheme
>promised, I suggest that the Scheme Authors some how show support for
>Stallman's effort.  Maybe the group should post an endorsement of
>GEL on gnu.announce.  What do you think we should do to help?

[1] An endorsement.

[2] A discussion of Scheme<->GEL issues with recommendations.


Opinions follow...

>                      The GNU extension language plan
>
>Here is the plan for achieving the design goals stated above.
>
>* Step 1. The base language should be modified Scheme, with these features:
>
>** Case-sensitive symbol names.

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?


>** 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 do *not* favor a change in the Scheme language to support this.  {Hey,
call it GEL 8^}.


>** Convenient fast exception handling, and catch and throw.

ya

>** Extra slots in a symbol, to better support
>   translating other Lisp dialects into Scheme.
>** Multiple obarrays.

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.

>** Flexible string manipulation functions.

ya

>** 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.

>** Two interfaces for call-outs to C code.
>   One allows the C code to work on arbitrary Scheme data.
>   The other passes strings only, and is compatible with Tcl
>   C callouts provided the C function does not try to call
>   the Tcl interpreter.

ya.  Again a standard FFDI (foreign function and data interface) would be
helpful.  Another alternative is SOM {IBM's system object model} or ILU
{Xerox PARC's Inter-Language Unification model} --i.e. use a 'language
neutral' IDL {Interface Definition Language} which describes a library
interface and which is translated into each target implementation.  [Sorry
about the acronyms]


>** Cheap built-in dynamic variables (as well as Scheme's lexical variables).

ya

>** Support for forwarding a dynamic variable's value
>   into a C variable.

ya

>** A way for applications to define additional Scheme data types
>   for application-specific purposes.

ya

>** A place in a function to record an interactive argument reading spec.

I am not sure what this is...

>** An optional reader feature to convert nil to #f and t to #t,
>   for the sake of supporting Lisp as well as Scheme.

Alternate readers are no problem.  We should seriously consider an
alternate infix syntax as well  (yuck, but if it wins for some...).

>** An interface to the library version of expect.

What is "expect"?

>** Backtrace and debugging facilities.

ya


                        --- E O F ---