<div class="gmail_quote"><div>Hi.<br><br>That's my first participation here, let's hope it will be meaningful and not too rude…<br><br>My
first remark is about the meaning of the steering commitee itself: is
it supposed decide instead of me (as a group of "preferred"
representents of the community), or is it supposed to be the entity
that will actually listen to what I say, and care about it?<br>
<br>I have this feeling that R6RS has been decided disregarding the
opinion of "casual" users, or worse, "potential" users, and that many
wasted time fighting on details that would have been implemented in a
way or another (and potentially fixed later) in other communities.<br>
<br>I am now wondering: what do implementers want? Do they want *their* language for themselves, or do they want it used?<br>I
want to support the latters. I consider that the formers want as little
features in the langage so that they can implemented what they want,
how they want, and not care about the rest of the community
(portability and joint work).<br>
<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Interesting! I feel like, if Scheme had a "industrial features" added<br>
it would be perfect for industrial users. I don't want to use CL.<br>
<br>
Do you think that they can be added without ruining the core?<br>
<br>
Why not define the core plus the optional industrial add ons? Why<br>
can't we have our cake and eat it too?<br></blockquote></div><br>That sounds a bit like what Marc Feeley suggested and like what I ask for.<br>A
small kernel, and optional addons that evolve independantly. Yet,
addons should have *perfect* semantic and API match: it the (winning)
API states "to remove an element, do (hash-set! h x #f) ", they one
should not give a different semantic to this and, say, "(hash-delete h
x)".<br>
Any implementation that doesn't support properly the specs should be considered as not supporting it at all.<br>This should make compatibility issues clearer.<br><br>On
the other hand, I don't consider the look of the module system a
compatibility issue. It's like porting from ASDF to mudballs or old
defsystem in CL. Bits of tweaking, yes, but still the same language: my
code will run as it.<br>
<br><br>To recapitulate my wishes:<br>- A commitee that cares about the
users of the language. All of them. And that makes voting periods last
more than a couple of weeks too<br>- A small language<br>- A HUGE set
of extensions to whatever has not been set in the language (and that
may involve huge changes in the core interpreter too, I do *not* care).
I would see there non blocking IOs, sockets, threads, complex numbers,
SRFI-1, hash-tables, multiline comments, blah blah<br>
- An breeding pool for everything else: module systems, home-made FFT,
"litterate scheme" parsers to write runnable blog posts. A mix of CPAN,
SRFIs and of gambit's dumping ground. Here, compatibility is no more,
but code is given a chance to be the next buzzword or in the next
revision on the official extensions.<br>
<br><br>You may not share my point of view, but I think that Scheme
should stay small for the purists, while being (portably) "as bloated
as {Ruby, Perl, CommonLisp}" for those who like the language and yet,
want to use it for practical purposes using their favourite
implementation.<br>
<br><br><br>So, how many potential members of the commitee would consider these requests as a potential evolution of Scheme?<br><br><br>Adrien<br><br clear="all"><br>-- <br>Français, English, 日本語, 한국어<br><br>