On Thu, 2009-02-19 at 13:30 -0800, Ray Dillinger wrote: > > There's a compelling case for a scheme-oid lisp with a > > "strings as immutable values" interpretation where > > characters are just strings that happen to be short. > > It would be cleaner semantics than R6, but such > > a large semantic change and breaks so much existing > > code that I can't imagine that it's likely to be a > > reasonable direction to go.
I disagree - sorta. Let us suppose that "core Scheme" came to have: 1. A mechanism for creating disjoint types.[*] 2. Immutable strings, only. Then it is easy to implement mutable strings like the current ones in a library. If the underlying implementation emphasizes sharing (e.g., a functional implementation of ropes or a shared-substrings implementation of UTF-8 strings) then it is even *efficient* to do it this way. -t [*] The essential characteristics that I mean by a "mechanism for creating disjoint types" are: 1. A way to allocate, as a first class object, a new type identifier. 2. A way to populate a new type by taking an arbitrary value and "wrapping" it in a pair of type identifiers we can dub the "public" and "private" type of the new value. Such that... 3. The wrapped value can be retrieved only by presenting the private type identifer alongside the wrapped object, and... 4. The public type identifier can be retrieved given only the wrapped value itself. And, along-side these: 5. A mechanism for defining generic functions whose various implementations can be separately and independently defined, but with sufficient reflective capabilities for programs and people to examine and reason upon the function that emerges from a bunch of separately loaded definitions of a given generic. AFAICT, 1..4 are simple enough but I'm not sure 5 is possible to do in a Scheme-ish way. The problem with 5 is to find consensus on a dispatching model. Fixed models of dispatching are likely to lack a generality Schemers are likely to want (or else we'd all be programming in Oaklisp or T). A fully general meta-object protocol of the classical sort is attractive except that it's size and complexity are unattractive. To accomplish 5 would seem to require some innovation in discovering something at once simple enough and general enough to do the job and fit comfortably in or near the core. I dabbled in this area years ago and my recollection of the design space is that I think it can be done - but it's not *easy* either to do or then to convince others that you've done it. -t _______________________________________________ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
