On 2009-09-05, at 19:03, Brian Harvey wrote: > I can see why compiler writers might be happier without LOAD. > That's why I'm > no longer convinced about the subset principle. Someone who wants a > tiny > Scheme to be used in the computer inside a toaster or something > might actually > want a WG2 Scheme, if the latter is clever about not loading unused > libraries. > That is, there might be a large WG2 Scheme compilerthat generates > small, fast > executables.
I will confess I have never written any toaster control software (I was peripherally involved in programming an air-conditioner many aeons ago), but I can envision allowing people to create their own toast pattern modules, which might be dynamically loaded :). If you see a toaster with a USB port, you know you're in trouble :) There seem to be 3 justifications for LOAD. 1. dynamically loading code during development (this of course includes all teaching uses) 2. dynamically loading code received from a remote source 3. dynamically loading plug-in extensions Uses 2 and 3 really require some kind of sandbox technique, unless you aren't at all concerned about injection attacks. I don't know a stronger argument for supporting first-class environments than that! I'd actually like to see LOAD defined to work well in cases 2 and 3, but can live with out that if it's impractical. I'd suggest that Core Scheme can have a specification for LOAD that says what environment the code is loaded into, and then goes on to say that the locations where code may be loaded from are implementation- dependent. Toaster Scheme may state that the set of locations is empty, which still complies with the standard, in an ugly, trivial way. Another implementation might define the method by which code is loaded to support the emerging `.implementation-name.ss' convention. This may sound as though it contradicts my earlier comments about no options. Not so, I don't want to see LOAD being an option (because that opens the way for much nastier options). But stating that an implementation can restrict the effectiveness of LOAD seems entirely reasonable to me. I would venture to say that there is no other feature of existing Scheme that is wanted in the core language but not in `clever compiler' Ultra Scheme. So I believe we can address the problem without needing an incompatible subset. -- v _______________________________________________ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
