[plt-scheme] Are new Schemers supposed to be reading SRFIs?

As an outsider (wannabe-schemer) I would have to say I agree with your 
arguments. When I was first looking at this mailing lists and other 
media describing PLT Scheme, I was asking myself, what on earth are 
those SRFI's? It wasn't difficult to find out the definition of SRFI, 
but the numbers still seem completely confusing to me - they don't mean 
anything!
In a compiled programming language I've been using for many years, it is 
possible to assign values to compile time parameters, which basically 
work like variables for the compiler. So if someone have been "smart" 
one time in the past and used integers to save space instead of a a 
string code (simplified: 1-male 2=female 3=other) I would assign the 
integer values to compile time parameter with the proper name, so that I 
can refer to for instance "sex-male", "sex-female" and "sex-other" in 
the code, and thus make it more comprehensible.
Would it be possible to do the same with the SRFIs?
When referencing them in the code, we can use names like "strings" 
"lists", etc. and the interpreter will just translate that to the proper 
number without us needing to know or even see the number.
Then when SRFI-300 comes along and replaces SRFI-1, all you need to do 
is to update this translation table.
Just my 0.02... At least it *sounds* simple :)

Ronny.


Noel Welsh wrote:
> On 5/11/07, Eli Barzilay <eli at barzilay.org> wrote:
>> Yes, but consider a different future: the new "srfi-300" list library
>> comes out, *then* people start talking about the need for common names
>> and obviously they want to choose "list-old" for srfi-1 and "list" for
>> sefi-300.  At this point you're stuck.
>
> This is a classic CS argument. Do we build a system that works for all
> time, but is inconvenient, or build something that is convenient but
> might break in the future?  The Right Way answer is the former, but I
> prefer the later.  Here are two reasons:
>
> - Gaining users now is more valuable than gaining users in the
> future, due to the same reason money now is more valuable than in the
> future: the return the language gets from today's users via increased
> libraries and visibility will pay off as greater usage in future.
>
> - PLT Scheme has to be prepared to (and does!) break compatibility
> between releases.  If I wanted a language that wasn't on the cutting
> edge I'd use Python.  The key differentiating feature of PLT Scheme is
> that it incorporates the latest research, which necessitates revising
> old decisions.
>
> These kinds of arguments go against the classic CS culture but I think
> they are compelling in a more realistic world view. YMMV.
>
> N.
> _________________________________________________
>  For list-related administrative tasks:
>  http://list.cs.brown.edu/mailman/listinfo/plt-scheme
>