[plt-scheme] Re: Scheme Steering Committee Position Statement

> To your list, I would actually add:
>
>   R7BS Bytecode: a bytecode that conforming compilers can write, and
> that conforming
>   run-time environments can read, in addition to which evernative
> compilation strategy
>   they use.

I propose the following extensible bytecode: Code 40 would denote a
function call, a macro to expand, or a list, depending on the context.
Codes 97 to 122 (and a few more) would combine to indicate an abstract
location, that itself could designate a variable or macro. Codes 32,
10, 13, 8 (not recommended) and some more would separate elements of
the bytecode. Code 39 would be a magic reflection operator allowing to
access some high-level representation of what might otherwise be
compiled. Codes 48 to 57 would help encode immediate numeric
constants. Code 41 would denote the end of the function call, macro,
or list. etc. This may sound painful, but with a proper bytecode
editor, and proper training, it could even be somewhat human readable!

Now to agree what the predefined abstract locations guaranteed to be
bound (and none others) and to what, in the initial context.

> If all the Schemes are so different that they might actually be
> different languages, and if bytecode is the solution to
> interoperability between languages in the JVM/CLR/Parrot world, then
> perhaps the Scheme world should have its own bytecode too.

My proposed solution to interoperability is: have a big
multibillion-dollar company or government push for the use of R7RS,
and lots of people will follow suit and interoperate with it.

[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
Oh, he's sincere all right. The question is: what is he sincere about?
        -- John McCarthy