Ron Garret  <rNOSPAMon@flownet.com> wrote:
+---------------
| It is possible to quote code as data in Python, it's just that the data 
| type used to represent code in Python is the string, not the cons cell.
| 
| That symbols are not first-class data types is a consequence of that 
| decision.  It is easy to add a symbol type to Python, it's just that the 
| Python compiler wouldn't make use of it (since programs are strings).
| 
| BTW, the exact same thing is true of Scheme.  Scheme programs are 
| strings too (at least they were in r5rs.  Maybe things have changed.)
+---------------

Actually, IMHO that's a sort of (unhealthy) community myth the Schemers
[and their standards] adhere to. You can't even read the introductory
section on syntax in R5RS without realizing they're not actually serious
about that "Scheme programs are strings" thing:

    1.2 Syntax

    Scheme, like most dialects of Lisp, employs a fully parenthesized
    prefix notation for programs and (other) data; the grammar of Scheme
    generates a sublanguage of the language used for data. An important
    consequence of this simple, uniform representation is the susceptibility
    of Scheme programs and data to uniform treatment by other Scheme
    programs. For example, the eval procedure evaluates a Scheme program
    expressed as data.

    The read procedure performs syntactic as well as lexical decomposition
    of the data it reads. The read procedure parses its input as data
    (section 7.1.2), not as program.

    The formal syntax of Scheme is described in section 7.1. 

To emphasize the point: THE EVAL PROCEDURE EVALUATES A SCHEME PROGRAM
EXPRESSED AS DATA. *Not* as a string!!! See for yourself, in any R5RS
Scheme implementation that you have access to:

    > (eval "(+ 1 2)" (scheme-report-environment 5))
    "(+ 1 2)"
    > 

What? It didn't evaluate the string? Nope. You need an s-expr for that:

    > (eval '(+ 1 2) (scheme-report-environment 5))
    3
    > 

And "6.5 Eval" reaffirms that EVAL takes Scheme data, not strings:

    6.5 Eval

    [[procedure]] (eval expression environment-specifier)

    Evaluates expression in the specified environment and returns
    its value. Expression must be a valid Scheme expression
    represented as data, and environment-specifier must be a value
    returned by one of the three procedures described below.
    ...

As far as I can tell, the "Scheme programs are strings" myth was
introduced only to make Chapter 7 "Formal syntax and semantics"
easier to write, but IMHO it only ends up obfuscating the true
nature of the language by not providing an interpretation of Scheme
data constructed by any means *other* than the rreader. Consider:

    7.1.2 External representations

    <Datum> is what the read procedure (section 6.6.2) successfully
    parses. Note that any string that parses as an <expression> will
    also parse as a <datum>. 

Yes, <datum> is a description of an external string, but once *parsed*
it is no longer a <datum>, but merely "Scheme data" -- "the objects
themselves" which READ returns.

    6.6.2 Input

    [[library procedure]] (read)
    [[library procedure]] (read port)

    Read converts external representations of Scheme objects into the
    objects themselves. That is, it is a parser for the nonterminal
    <datum> (see sections 7.1.2 and 6.3.2). Read returns the next
    object parsable from the given input port, updating port to point
    to the first character past the end of the external representation
    of the object. 

By pushing the BNF for <datum> -- and by extension, <expression> --
onto external string representations, they've make it absolutely
impossible to rigorously specify the structure of Scheme objects
created ab initio as data by Scheme procedures *other* than the
built-in READ procedure!! Hint: You can build all the "Scheme objects"
you want (by consing & such) which are legal arguments to EVAL,
but they won't be <expression>s!! Madness!

Yes, those who criticize Scheme for this myth have it right.
Common Lisp took the sane path: In CL a <datum> is a CL object,
*not* a string. And <expression> [or, rather, a <form> which
is a conforming program] is a subset of <datum>. The CL reader
is just *one* way [albeit a standarized way] to contruct a
<datum> from an external string.


-Rob

-----
Rob Warnock			<rpw3@rpw3.org>
627 26th Avenue			<URL:http://rpw3.org/>
San Mateo, CA 94403		(650)572-2607