On Mon, Sep 21, 2009 at 09:22:54PM -0400, John Cowan wrote:
> A third alternative is to omit binary I/O altogether.  One of the use
> cases for small Scheme, however, is in embedded systems.  If you don't
> have any files, but do process packets from the network, you need to be
> able to transput those packets without interference from any encoding.

I don't see that (use case), and think that your "third option" is actually the
right one.  This doesn't make these problems go away, but pushes them into
thing-2, where a proliferation of names is perhaps less of a problem.

Why would thing-1 necessarily have to contain all of the workings for a scheme 
for
embedded systems?  I can't see how it could.  Embedded systems need a mechanism
for creating "blob" (byte-string) references at explicit addresses (unmanaged by
the GC), a whole host of bit-bashing operators, and lots of other things that 
also
probably don't belong in thing-1.

I see thing-1 as the exact minimum that allows analysis, description and 
teaching
of algorithms.  Maybe I'm wrong there, and some people want to have a real 
thing-1
as their only thing, and so want to squeak some practical, real-world 
capabilities
into it.  I don't see that as its purpose.  I'm happy for all of those
external-environment-facing issues to be handled by library functions (and I'd 
be
happy if there was some standardization there, through wg2).  I'd like to see
thing-1 describe the "language" that joins those libraries together into working
programs, that is the root of the commonality and portability of algorithms.  
The
working vocabulary can be extra.

I expect all embedded system schemes to be some subset of thing-2, as would all
"practical" schemes that are used for writing whole applications.
Embedded/scripting/extension scheme might be mostly thing-1, but with a big dose
of application-specific features to control.  I wouldn't expect to find an exact
thing-1 outside of a teaching environment, or implementation-technique thesis.

Cheers,

-- 
Andrew

_______________________________________________
r6rs-discuss mailing list
[email protected]
http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss

Reply via email to