On 9 Sep 2009, at 9:18 pm, Eli Barzilay wrote: >> Pessimism! I've seen much good practical work done in Scheme. Not >> very much, I agree, but certainly not none... > > Note that I wrote "Scheme", not Scheme. >
Ah... >> As it stands, there are languages called [...]. > > Right -- and some of these things are *far* from being just a matter > of writing (foo) instead of (bar). For example, in PLT there are > custodians that are in charge of resources like memory, threads, and > ports; they are extremely useful for writing robust servers -- and > there is no way to write some quick text that will replace a PLT > (custodian-shutdown-all c). Same goes for many other things. *nod* Such falls into the "implementation features" camp. Portable code wishing to take advantage of this feature should be written to not assume it exists, but might wrap suitable units of code (requests in a server app framework, for example) in custodians that get shut down at the end of the request, and specially tag each managed value that is meant to escape the dynamic scope of the request for any reason, ideally through innocuous "call-with-request-dynamic-scope" and "mark-value-as-escaping-request-scope!" functions that, on PLT, happen to establish a new custodian and shut it down on completion, and to transfer a value to a global custodian, respectively; yet on other implementations, might be defined to do nothing. Portable code must not rely on custodians being present, but can by all means use them if available to improve your security from resource leaks. At least, that's how I'd handle such a feature in portable code... and nonportable code is not an interesting case for a standard to be worrying about :-) So what this tells us from an R7RS perspective is that it'd be nice to have a standard facility to ask that a block of code be totally ignored (not even macro-expanded, lest we use implementation-specific macros that throw up errors in other implementations) if we're not on a particular implementation. >> We need to keep it beautiful, because that makes programming more >> productive. But that's in no way contradictory to making it >> practical. > > Yes, of course there is no contradiction between the two. But you > need to accept that more features means a bigger spec, and you need to > accept that this does *not* mean less beautiful. Definitely. I'm all for the spec being bigger, as long as it's justifiable growth. > This obsession with > a 50-page limit for the spec is suffocating the language (and the > post-r6rs noise is a perfect example of this). 50 pages is by no means magical! I'm more interested in keeping features that aren't necessary for "being Scheme" out of the (core) spec, and standardising them elsewhere (SRFIs) or as "optional" extensions to the spec. Because I want it to be easy to produce a basic-but-functional implementation (sure, it might not have many features that can't be implemented as a library defining macros and procedures in terms of the core, but there's a lot of good work you can do with that), or implementations with very small footprints. > The same goes for > accepting compromises -- a more practical language means that there > are more compromising to do, and r6rs actually went through these. > This is very different from r5rs (and earlier) where the solution to a > problem that requires compromising was to just not include it (and > pray that the One True Solution will present itself to us in the next > decade(s)). I agree mainly, but I think that before accepting a compromise, we need to look hard to see if there's a way of having our cake *and* eating it. Such as portably taking advantage of custodians if they're available, while still operating correctly if they're not (as above). ABS -- Alaric Snell-Pym Work: http://www.snell-systems.co.uk/ Play: http://www.snell-pym.org.uk/alaric/ Blog: http://www.snell-pym.org.uk/archives/author/alaric/ _______________________________________________ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
