Stephen Lewis scripsit:

> In the R7RS standard, are macros (i.e syntax objects) considered to be
> first-class objects?

No.  (Everything in this post applies equally to R5RS and earlier, and
indeed to R6RS except that R6RS requires implementations to signal a
syntax error where this post speaks of undefined behavior.)

> For example would these examples be considered to be standard
> compliant R7RS Scheme? The implementations to which I have access do
> not all behave in the same way.
>
> Storing a syntax object in a variable?
>
> (define myand and)

The behavior of that definition is not specified by the standard.  In
general, a syntax keyword is recognized only when it appears literally
in the first position of an expression.  Implementations are free to
reject such a definition definition, or to accept it and initialize
"myand" with some object; the properties of this object are not
specified by R7RS.

See <http://trac.sacrideo.us/wg/wiki/SyntaxAbuse> to see what various
implementations do with (eqv? 1 do), where "do" is the standard syntax
keyword.

> I find that there are "Primitive Expressions" and "Derived
> Expressions" and that derived expressions "can instead be defined as
> macros" but this does not seem to be a requirement.

The distinction between primitive and derived expression types is
pedagogical rather than fundamental.  It is common to implement "cond"
as a macro on top of primitive "if", but it is equally correct to
implement "if" as a macro on top of primitive "cond" as Elisp does, or
to treat "if" and "cond" as both primitive.

No distinction is made between primitive and non-primitive procedures in
the standard (that is, between those not implemented in Scheme and those
that are implemented in Scheme).

> The description of a procedure call although in the Primitive
> Expression section does not appear to exclude syntax objects.

The first subexpression of a procedure call must evaluate to a
procedure, but a syntax keyword is not an expression.

> What about (and and) which is an expression that returns a syntax.

"(and and)" is an error (that is, the behavior is undefined).

> The WG1 charter asserts that "Self consistency is an important
> objective," and yet the boolean operators and arithmetic operators do
> not behave consistently.

That is unavoidable.  In Scheme, all procedure calls are processed
uniformly: the arguments are expressions which are evaluated before the
procedure is invoked.  In a syntax expression, however, the arguments
are treated in a way that is determined by the syntax keyword.  Thus,
"if" evaluates its first subexpression, and only then determines whether
to evaluate the second subexpression only, or the third subexpression
only.  "And" and "or" evaluate just enough subexpressions to determine
the return value, leaving the rest unevaluated.

It's easy to write your own versions of "and" and "or" that are ordinary
procedures, in which case all the sub-expressions will be evaluated in
advance.

> In particular as a user of the language it is not obvious which
> functions have been implemented as primitives and which as a syntax.

That's true.  In the standard, procedures (primitive or not) appear in
chapter 6, syntax (primitive or not) in chapter 4.  When reading code,
you simply have to keep track of the syntax keywords of the program
mentally.

> It appears to be valid to implement the "and" function as a primitive
> or as a macro and curiously the boolean "not" function is listed with
> the Standard Procedures making it inconsistent with the other boolean
> operators.

"Not" is indeed an ordinary procedure, because its single argument is
evaluated in advance.

> There is another situation in which the difference between primitive
> procedures and syntax objects makes itself a nuisance and that is in
> short-cicuit evaluation of the boolean operators. In the following
> expression one might think that the "never" object was not evaluated:
>
> (and #f never)
>
> and yet if the "never" object is a syntax it would seem that it is
> evaluated.

It can't be a syntax form, because a syntax form is a list whose car is
a syntax keyword.  It must be a variable, and it will not be evaluated.
However, if it is not even defined, that is an error.

--
John Cowan      <cowan@ccil.org>       http://www.ccil.org/~cowan
                Charles li reis, nostre emperesdre magnes,
                Set anz totz pleinz ad ested in Espagnes.

_______________________________________________
Scheme-reports mailing list
Scheme-reports@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports