Newsgroups: comp.lang.scheme
Path: cantaloupe.srv.cs.cmu.edu!rochester!udel!gatech!news.sprintlink.net!demon!uknet!liv!news
From: bruce@liverpool.ac.uk
Subject: wish list for scheme (and GUILE) (was Re: Lisp Pointers: Scheme: TNG)
In-Reply-To: thorn@goldmund.irisa.fr's message of 23 May 1995 09:24:03 GMT
Message-ID: <BRUCE.95May24113854@iasc3.scm.liv.ac.uk>
Sender: news@liverpool.ac.uk (News System)
Nntp-Posting-Host: iasc3.scm.liv.ac.uk
Organization: IASC, University of Liverpool
References: <3oukcs$98s@nntpd.lkg.dec.com> <PK.95May16134657@kaulushaikara.cs.tut.fi>
	<RAMSDELL.95May19115428@goblin.linus.mitre.org>
	<THORN.95May20040633@goldmund.irisa.fr> <3ppdma$5me@info.epfl.ch>
	<THORN.95May23112403@goldmund.irisa.fr>
Date: Wed, 24 May 1995 10:38:54 GMT
Lines: 94

>>>>> "Tommy" == Tommy Thorn <thorn@goldmund.irisa.fr> writes:

> stefan.monnier@epfl.ch writes:
>> I don't really care about evauation order. It's probably a good
>> thing to make it undefined (forces people to make such
>> order-dependent code explicit).

> The only thing it forces, is a lot of unportable code.  It's quite
> easy to write code that depends on the order of evaluation, if
> you're not careful.

> More like a principle, I don't like non-deterministic semantics
> where they can be avoided.

Hmm.  No, neither do I, which is why I try to write code carefully!
Scheme already provides ways to evaluate things in particular orders,
should that be necessary; I think the cases when I want to evaluate
arguments in a particular order are pretty rare, so I'd rather add a
special form to the language for this rare case (presumably this could
be done with a macro relatively easily).  

Given the existing semantics (that code that relies on evaluation
order is not portable) does that mean that the evaluations could, in
principle, be evaluated in parallel?  (I have a feeling that that's
not so, unfortunately.)  If so, then that strikes me as a potentially
valuable feature.


Speaking as a potential scheme user (I'd like a single language which
could provide the same functionalities as TCL/Tk, awk, the database
bits of Perl, etc.) here's my wish-list.

* A module system.  I don't much care how it's done, but it ought to
be efficient.  (In general, I'm concerned about efficiency; that's a
reason for not wanting to specify evaluation order, because that's
a flexibility I'm quite willing to give an optimizer.)

* Some standard modules.  Some of the stuff in the existing report
clearly belongs in modules (libraries, if you prefer).  It would be
nice to be more confident of the stability of bits of SLIB.  Something
that appears to be missing is binary I/O; this isn't a problem most of
the time, but there are some cases where I really need that (where I
know that messages are going to come from /dev/fd4 as groups of 4 32
bit ints, for example, or where I want to send messages of that form).

* Some way of defining new opaque types, preferably object-oriented.
I realise this can be done within scheme, but the modules could
probably be made more usable with this, and it would be nice for them
all to use the same system.  In addition, explicit syntactic support
would make building a nice environment easier: I want emacs to be able
to point me to where things are defined, whenever it reasonably can.


And then there's the specific implementation issues.  (I suppose this
is more comment to the GUILE team, since they seem to be most likely
to produce something that I'll want to use.  I also realise that STk
offers many of the things I want, as does Perl for that matter; I am,
however, very much a cat person, and Perl doesn't seem to suit me.)

* Dynamic loading.  It's important that GUILE has a small footprint,
because of the different uses I'm going to be putting it to.  TCL
doesn't have dynamic loading (or rather, it has several different
implementations of dynamic loading), but then I don't use wish as a
substitute awk.

* It needs a good emacs mode; as good as elisp-mode, if possible.
Scheme should look pretty, just like elisp does with font-lock turned
on, and the Functions menu should let me find where things are defined
(whenever reasonable).

* As with all programs, it needs documentation that'll only be
available about 2 years after it's out of date, and it needs
robustness!  A major reason for using TCL/Tk is that it compiles
easily on many systems, works when it's compiled, and has large
quantities of nice documentation.  TCL may not be an ideal language,
but for some things it works, and that's enough.


Other things are less important.  ctax would be nice, as would rush.
Compatibility with JAVA is of no importance, though if I knew anything
about it I suppose it might be.  The work underlying this is
potentially valuable: efficient object-oriented support is of value,
as is the ability to have static typing for some variable instances.
In fact, just adding the ability to say that certain things are going
to be fixnums has got to be a Big Win for efficiency.

GUILE is clearly getting there (the snapshot is heading in the right
direction, in most respects); I think it has every chance of taking
over the known world, just like PL/1 and after it, Ada.  (Only
kidding.)
-- 
Bruce                   Institute of Advanced Scientific Computation
bruce@liverpool.ac.uk   University of Liverpool

