Re: Experience issues

["Bradd W. Szonye" <bradd+srfi@xxxxxxxxxx>]

> Bradd W. Szonye wrote:
>> While redefining the original "vector-set!" may work well on the
>> Scheme implementation you're using, it would work horribly on PLT
>> Scheme. (SRFI-44 is not alone there. SRFI-1 has a few interfaces
>> which just don't work on PLT.)

scgmille@xxxxxxxxxxxxxxxxxx wrote:
> SRFI-1 is a well designed SRFI.  That anything in it cannot be
> implemented in PLT (which I'm quite surprised of) would speak poorly
> of PLT, not the SRFI.  

You can do it, but the result is not even remotely usable or convenient
for users. The problems come from the extended R5RS functions. There are
two ways to make them work, both of which have disadvantages:

1. Roll them into the interpreter's core language.
   Disadvantages: Implementors are reluctant to do it, because it
   introduces a silent change to the core language, and users can't
   easily do it themselves. Implementors would rather use these as
   optional libraries.

2. Implement them as an optional library.
   Disadvantages: This doesn't work well in PLT when the library makes
   changes to core-language interfaces. If you write a module in R5RS
   Scheme, you can't redefine the R5RS bindings. Unlike Scheme-48, the
   PLT module system does not permit shadowing (and for good reason,
   IMO). You can avoid this by implementing a SRFI as its own language,
   but then you run into the same problem when you try to combine two of
   them.

This is *not* a flaw in PLT's module system. It's a flaw with SRFIs that
try to change the meaning of the core language. Implementors want to
make them optional, because not everyone wants them, but it's very
difficult to combine core-language changes like this orthogonally. It's
a rock and a hard place.

>> Basically, I'm asking whether you've eaten enough of your own dogfood
>> to know what it tastes like. If not, you may want to hold off on
>> releasing the SRFI to know whether it's something people will
>> actually *want* to use.

> I've eaten similar dog food in a lot of languages.  If someone else
> volunteers to do what you ask, great.  

Until you eat your *own* dogfood, you don't know whether it tastes good.
And I'll repeat what I said to Taylor: Until you've actually used this
to create concrete collections, you're publishing a "Scheme Request for
Design Docs," not a request for implementation.
-- 
Bradd W. Szonye
http://www.szonye.com/bradd