[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

LAND* specifications in RnRS-style

This page is part of the web mail archives of SRFI 2 from before July 7th, 2015. The new archives for SRFI 2 contain all messages, not just those from before July 7th, 2015.



       Let me first express my deep appreciation to Jim Blandy. He not
only gave insightful comments, but also showed the right way. This
message is to express my agreement and appreciation, and to clarify a
few remaining points.

> The notation used to describe LAND*'s semantics is also unfamiliar.

It's a denotational specification. It is the third way of formally
specifying semantics, the other two being operational and
axiomatic. What you propose as "semantics, specified informally, in
English" and "semantics specified as an R5RS macro" are both
operational specifications. I concur that this is the most common and
familiar way; thus your proposal wins.

Just as a side note: denotational semantics has an advantage that it
can be carried out as it is. If one has a Scheme interpreter written
in ML/Haskell or Prolog (as Gambit originally was), my denotational
specification can be taken almost literally as an implementation of
LAND*.


Just to re-state my agreement:
    Syntax: (land* (<clause> ...) <body> ...)
    Each <clause> should have one of the following forms:
      (<variable> <expression>)
      (<expression>)
      <bound-variable>
    Each <variable> or <bound-variable> should be an identifier.  Each
    <expression> should be a valid expression.  The <body> should be a
    possibly empty sequence of expressions, like the <body> of a
    lambda form.

This is very concise and precise. The only nitpick is that the
original syntax allowed LAND* without any <clause> ,as in (land* ()
<body>). But this is really a very minor matter.


    Semantics: A LAND* expression is evaluated by evaluating the
    <expression> or <bound-variable> of each of the <clause>s from
    left to right.  The value of the first <expression> or
    <bound-variable> that evaluates to a false value is returned; the
    remaining <expression>s and <bound-variable>s are not evaluated.
    The <body> forms are evaluated iff all the <expression>s and
    <bound-variable>s evaluate to true values.

I would only suggest replacing 'true values' with 'non-#f values'. For
 example, 
    The <body> forms are evaluated iff all the <expression>s and
    <bound-variable>s evaluate to values other than #f.

I feel this expresses better the spirit of LAND*, and the fact that
there are many truths.

Name. I have no particular preference for LAND*. If let-and, and-let*,
or even and* sound better or more appropriate, so be it. My original
choice was and*, but I was afraid it's too vague, and would be
objected to anyway.

> Isn't a <clause> of the form <bound-variable> equivalent to one of
> the form (<bound-variable>)?  The fact that the list contains only one
> element shows that no binding should be created.  Thus,
> <bound-variable> clauses seem unnecessary.

I agree that it's indeed possible to tell between binding to a new
variable and referencing an already bound variable, as the first
construct must be a list of exactly two elements. I however feel that
there ought to be some "distance" between valid "codewords", and not
all possible codeword values should have meaning. Space between
codewords increases robustness of a code.

	Thank you very much for your comments and specifications. They
really _feel_ RnRS!

	Oleg