This is the mail archive of the guile@cygnus.com mailing list for the guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Planned presentation at The Bazaar


"Wade Humeniuk" <humeniuw@cadvision.com> writes:

> >It should also be noted that the existance of a group of standardized
> >features in scheme would make it quite trivial to implement a cl
> >compatable module, so that everyone's tastes can be catered to. I have
> >a few modules laying around that provide some cl style things, like
> 
> 
> Or implement scheme in CL.  They are essentially the same language.
> A Scheme that implements CL would not be small anymore, but
> would be CL.

The library approach means it's not all in the core, but there if you
want (or need) it. My point here being, that if you really want the
features (and misfeatures, like syntax abbhorations) of cl, it should
be much easier to accomodate if you already have a standard library
available in scheme that implements the same basic functionality
(hashtables, struct-like objects, etc). It has no effect on anyone who
wants to use the spartan existing features of the core language, but
means that those who do want them don't have insane porting headaches
between scheme implementations (this goes for all programs, not just a
cl-scheme package).

It's obviously quite possible to implement cl under any existing
scheme implementation, but will require either:

1) Rewriting an awful lot of stuff just using the scheme core, which
   will likely be slower than any native implementations of the same
   type of thing. A lot of programming in scheme tends to require
   wheel inventing, actually, and I feel this is a very big drawback
   to scheme, which hopefully can be dealt with by having a collection
   of standard library features. The core will still be the only thing
   available by default, for teaching and 'real scheme programmers'.

2) Using the native features of a particular scheme, tying you to that
   scheme, unless you target each individual scheme, which is a lot of
   work, and probably more than anyone wants to do. It can also break
   between revisions of any specific scheme.

The gist of it is that, without a standardized set of (optional, but
available) features, you're better off just using cl (which is an
option, but there's a lot about cl to dislike). I'm not suggesting
that scheme take the approach of just cloning cl, but to have the
useful features available in a well-defined way.
-- 
Greg