I/O proposal

[Jonathan A Rees <JAR @ MIT-MC>]

    Date: Sat, 16 Mar 85 22:12:45 est
    From: Kent Dybvig <dyb%unc.csnet at csnet-relay.arpa>

    >   I disagree -- proliferation of special forms is a communicable disease.
        
    Addition of new syntax where new syntax makes sense is never
    harmful.  It's much more clumsy to use a function when what
    really makes sense is a proceedure.  Ninety-nine times out
    of a hundred people are going to type:
        (with-output-to-file "fudmich"
            (lambda ()
                ...))
    Adding an extra level of complexity (not to mention an extra
    level of nesting).

I would not argue strongly if you claimed that antispecialformism was a
purely religious position (although I'd wonder, since it's so strongly
held in some camps, such as the ones I belong to).  One rational
argument, however, might be not necessarily language simplicity, as you
suggested, but rather, program analyzability.  Any program-analyzing
program or human must know about ALL special forms in order to do things
such as free variable analysis and substitution; and there is much one
can say about a program without having ANY knowledge of the values of
free variables.  So, generally speaking, special forms add to the
complexity of program analysis, whereas procedures (i.e.  bindings) do
not, and therefore special forms are to be avoided.

This argument does not necessarily apply to macros (since macro forms
can be expanded), but since Essential Scheme is militant in not having a
theory of macros, that doesn't help much.

    If we continue to use functions where syntax is appropriate,
    pretty soon someone will suggest that the reader syntax
    "#'exp" should mean "(lambda () exp)".

Actually this is not so absurd.  I have from time to time toyed with the
idea of a reader syntax for (lambda () ...) in analogy to that for
(quote ...) for this very reason - the presence of such a thing would
often shoot down the conciseness arguments sometimes put forth in favor
of special forms.

Jonathan