This page is part of the web mail archives of SRFI 44 from before July 7th, 2015. The new archives for SRFI 44 contain all messages, not just those from before July 7th, 2015.
> 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