[r6rs-discuss] Programs and scripts

From: Lynn Winebarger <owinebar>
Date: Tue Nov 28 00:18:18 2006

Abdulaziz Ghuloum wrote:
>
> On Nov 27, 2006, at 10:53 AM, John Cowan wrote:
>
>> William D Clinger scripsit:
>>
>>> Good point. Clearly there are no draft R6RS programs except for
>>> scripts
>>> plus the libraries they import. By the phrase "real programs", I mean
>>> the much larger category of programs that were defined by the R5RS and
>>> earlier reports, which some R6RS editors have insisted are not ruled
>>> out by the R6RS. I welcome suggestions for a better way to refer to
>>> these non-R6RS programs.
>>
>>
>> I still do not understand. First of all, the standard cannot bind
>> anything that does not claim to conform to it, neither a program nor a
>> Scheme implementation. And second, what can one of this "larger
>> category
>> of programs" do that cannot be done by a script which imports libraries?
>> I take scripts and libraries to be the R6RS units of program
>> construction,
>> as files are in C and classes in Java.
>
>
> It's very simple, really. The "larger category of programs" is Scheme
> implementations since we know this area dominates all uses of Scheme.
> Can a Scheme implementation be written as a script? Maybe, but then
> it would need another implementation to run it! To break the need for
> having infinite scripts going all the way down, every Scheme
> implementation, at its root, must be a non-script. Seriously :-)
>
     It seems to me the #!/usr/bin/env argument could be ended by defining a
simple "program" file format and a (make-executable <source file name> [<exectuable name>])
form that converts the program file into a file executable on the host operating system.
The details would be implementation dependent, so the output could be a compiled
binary or a Unix script. For the purposes of this form, it would not matter.

     I'd also like there to be ways to specify alternative readers and macroexpanders.
Scheme is a language for language implementors, and it should be allowed to write languages
with complicated syntax and compilers from those languages into Scheme, and to have those
dropped in place automatically. In order to limit a reader's scope, it would need to be
either specified in the source form that loads/compiles a library/program or in the library/program
itself. The former idea is very ugly, and the latter would require library and program files to
be implicitly delimited.

    To be more specific, a source-reader would provide a stream of expression datums, and a
preprocessor would take an expression datum and return an expression datum.

     I am not sure how to make this a formal comment because having well-scoped readers and preprocessors
requires changes in the library format and, if extant, the program format.

Lynn
Received on Tue Nov 28 2006 - 00:17:38 UTC