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] |
"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