Ray Dillinger scripsit: > But this was a false dichotomy, because people who did not (and do not) > support R6 actually want at least two very different things.
Well, I'm going to evaluate my proposals against your two sets of criteria. Of course my proposals are *just* my proposals, not official, blah blah and blah blah blah blah. > One is the pedagogical language; expressiveness, simplicity, and > clarity, as Brian wrote above. Large implementations are fine here > if they abstract details in a nice way. My proposals provide 239 bound identifiers, so there is plenty of expressiveness. Simplicity, not as much as some want; that's life. Clarity, I hope so. > The "minimal" I/O requirements are all character-oriented. Binary I/O is in a feature group that implementations may omit. Then again, so is textual I/O. > Nobody has to worry about issues like encoding because that's all > taken care of in the implementation, By default. You can't portably count on the implementation providing any specific encodings for you. Nothing says that particular implementations can't do so. > and blobs can be implemented as general vectors holding u8 values, etc. Blobs are in a SRFI, but that's because they aren't ripe for standardization yet (unfortunately). R6RS did, but that was a mistake, even though they got many of the details right, or at least reasonable. The SRFI has a portable implementation in terms of general vectors, but nobody has to use it; most of the procedures in it can be inlined as a few instructions. (This claim is technically empty, because I haven't written up the SRFI yet; but trust me for now.) > The other (or at least another) is the embedded-systems language; > simplicity, clarity, and expressiveness are important, but the > implementation needs to be fast and small (possibly skipping parts of > the numeric tower for the sake of being small) Four kinds of optionality in the numeric tower; 12 other kinds elsewhere in the proposals. > and the "minimal" I/O requirement is byte-oriented. Binary I/O is a feature group. > Reading/Writing characters is secondary and may be supplied by a > library implemented in terms of bytes. Textual I/O is a feature group. > Blobs are *the* most important datatype, and have to be handled with > blazing speed. Then don't use the portable implementation, for sure. > Strings are secondary and may be supplied by a library implemented in > terms of blobs. I don't provide that possibility. > In fact there probably needs to be a way to designate that a blob has > a particular system address, or that parts of it are to be considered > "volatile" or writable by other processes, or else you can't write > device drivers or reliable FFI's. These are Good Things, and suitable for implementation-specific interfaces or SRFIs, but not (yet) for the standard. > I'm going to say straight up that WG1, pedagogical language, and WG1, > embedded-systems language, have conflicting needs that will be at best > difficult to reconcile in a single standard. Ah, but I (like Jurgen) am a monstrous clever fellow. Follow the bouncing ball.... -- "Well, I'm back." --Sam John Cowan <[email protected]> _______________________________________________ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
