[r6rs-discuss] One vote

From: Lynn Winebarger <owinebar>
Date: Thu, 16 Aug 2007 23:31:19 -0400

This thread has been enjoyable. I wish I had finished my explanation
prior to the final hours of the poll and posted it. Far too much discussion
was spent on the gritty points of the draft, rather than its underlying
flaws.

I did want to elaborate on my example mechanisms, as I think I have ways
to express my meaning more clearly.

On 8/13/07, Lynn Winebarger <owinebar at gmail.com> wrote:
> Instead of the approach taken by the R6RS draft candidate, the
> Schemey method would be to define generic mechanisms for implementing
> libraries and data types. One set of candidates might be:
> * a safe way of specifying the layout of data structures down to the bit,

      This removes an "unnecessary restriction". Many implementations allow you
to go to some other language and implement such data structures for use in
the Scheme system - why make programmers do this??? It's offensive.

> * extending the continuation model to communicating processes, and
    CPS and the call-by-value lambda calculus are the core of Scheme.
The only way to really move the core language forward is
to find a harmonious extension of these two devices to capture
asynchronous parallel computation. Then I/O can be dealt with sensibly
in the semantics.

> * a generic way of introducing distinct namespaces into a running system and
> providing linkage into other namespaces,
    What I should have said is two things:
   * a way to translate a representation of the core language into an
(operational)
     denotation, and
   * a way to introduce new namespaces and linkages between them so the above
     does not need 3D code to be interesting.

     The first has been provided by "load" or the REPL, or by eval on an
expression that side-effects the top-level environment (not R5RS eval!),
but can be considered as a separate mechanism. "Promoting" program
representations to executable objects is fundamental to Scheme, and
should be available in a principled way.

    Serializing (demoting) executable objects would be a nice symmetry.

> * defining program properties guaranteeing no dynamic memory allocation
> (similar to the tail-recursion guarantee).

    Scheme is both for the highest tower of abstraction and the lowliest
assembler code. How else can you write the storage allocator/garbage
collector in Scheme itself?

Lynn
Received on Thu Aug 16 2007 - 23:31:19 UTC