Formal comment #51 (defect)

Conflating programs and scripts
Reported by:	Andre van Tonder

Component:	scripts
Version:	5.91

Pages : 26-27 

Description

The report conflates three orthogonal issues - defining a program,
marking the entry point of the program, and marking the program as one
particular kind of Scheme program on one particular operating system
in one particular use case, a use case that, by many Schemers, is not
commonly needed, if at all.

The current report is allowing this one use case to strongly biase the
way Scheme programs are supposed to be organised in files. Although it
is not required by the report, implementations are likely to satisfy
it by requiring the "main" part of the program (in the script) to be
in a separate file from the rest, even when it makes no logical
organizational sense to do this.

An existence proof: Many current Schemes allows one to write portable
programs that will run on various operating systems, including Unix,
without having to include any operating-system specific details in the
text of the program.

A more common use case for many is compiling a program to an
executable binary. These do not require a scheme-script executable to
run, nor do they require special directives to satisfy an
infrastructure requirement for use case they do not need on one
particular operating system. The report therefore burdens, and
discriminates against, compiler-only implementations by requiring them
to provide unneeded facilities.

Presumably the intent of the authors is that a file containing a
script can be dropped without modification onto any system and will
just work. But the report states that the first line may contain
something else, and should be ignored. The report also does not
explicitly require the script part of a program to be in a separate
file, nor the #! directive to be on the first line of such a
file. However, in these cases, presumably it will not portably run on
Unix. In other words, the report blesses non-portable programs. What
is then the point of going to the trouble of specifying something in
the interest of portablity if it does not guarantee portability.

Marking the interpreter as part of the program text is an
idiosyncratic practice particular to unix scripts, conflating
orthogonal concerns. The Unix design is not necessarily a particularly
good design. It should not be adopted and blessed by the Scheme
report.

A large number of current and future Schemers do not often, if ever,
use Unix. Suggestion

Consider providing a definition of Scheme programs either instead of,
or in addition to, scripts, or modify the script specification by
removing the <script header> and most of the substance of 7.1.1., in a
way that does not accomodate, bless or otherwise favour a particular
use case on a particular operating system. Allow programs to consist
of libraries and entry point in the same contiguous text.

RESPONSE:

To address this comment, the current specification of Scheme "scripts"
will be replaced by a definition of Scheme "programs".  A "program" 
will have similar semantics to that given for scripts, but the 
specification will make no reference to files or a script header.  
A specification for packaging Scheme programs as scripts will be moved 
to an appendix or other auxiliary location in the report.  The issue 
of any operating-system specificity will be addressed in a rationale 
in the latter section.

Specific changes planned for the next draft are as follows:

1. In the "Description of the language" part of the draft:

   a. Sections 1.11 and 7, which relate to "scripts", will be replaced
      with sections that define Scheme "programs".

   b. All mentions of "script" in this part of the draft will be 
      replaced with "program".

   c. The (r6rs scripts) library will be renamed to (r6rs programs).
      The 'command-line-arguments' procedure will be renamed to 
      'command-line'.

   d. Any references to the script header and the "scheme-script"
      interpreter will be removed from this part of the draft.  
      These are addressed in point 2 below.

   e. A rationale will be provided for "programs".  With the "script"
      aspect factored out, the remaining rationale for programs is 
      that they provide:

       i. A more informal format for Scheme code, comparable to the 
          R5RS top level, but better-defined.  A more detailed 
          treatment of this issue is given in the response to formal 
          comment #39, "Script-body differences".

      ii. A portable way to specify an entry point into a body of 
          Scheme code.

2. A section specifying Scheme scripts will be added in a non-normative
   appendix, that will include the following:

    a. Specification of how a script relates to a Scheme program, 
       i.e. a script may be specified as a file (or some 
       generalization thereof, such as a "delimited piece of text") 
       containing an optional script header (e.g. beginning with 
       "#! " or "#!/"), which is followed by a Scheme program.

    b. Specification of the semantics of the "scheme-script" 
       interpreter. This will only be mentioned in this section.  
       The interpreter must ignore any script header and initiate 
       the execution of the remaining Scheme program.

    c. Brief descriptions of script handling on major operating 
       systems, such as Apple Macintosh, Unix, and Microsoft Windows.

    d. A note that R6RS-conformant implementations can omit script 
       support when appropriate, such as in implementations targeting 
       embedded platforms.

    e. A rationale for the inclusion of the above details in the report.