Re: [Scheme-reports] define-record-type queries
Aaron W. Hsu 05 May 2011 17:57 UTC
On Thu, 05 May 2011 11:52:56 -0400, Andre van Tonder <andre@het.brown.edu>
wrote:
> It may come up because the constructor takes field names. Here is an
> example:
>
> (define-syntax foo
> (syntax-rules ()
> ((_ name name? x get-x)
> (define-record-type name (make-foo y x) name? (x get-x) (y
> get-y))))
>
> (foo y y? y get-y)
>
> This generates a record definition with two fields symbolically given by
> y, but the two ys are not the same identifier (the y introduced by the
> macro has a different color or mark and is therefore different from the
> y passed to the macro).
>
> If an implementation compares field names using eqv? when coming up with
> the constructor definition, the above will fail. If it compares them as
> identifiers (using bound-identifier=?) the constructor definition will
> succeed fine.
*sigh* It appears that you are right here. On the other hand, I would
argue that you can't possibly justify a symbolic semantics here because of
this very situation: it's just incorrect. I suppose that in much of this,
when I am reading the standard, if it says that a field name is an
identifier, I take that to mean an identifier, with all of the associated
lexical information that goes with an identifier, I would argue that you
cannot read <field name> in the definition of define-record-type as a
symbol, and therefore it would be simply incorrect to test equality of two
identifiers (which are not symbols) using eqv? in this case.
A lot of the discussion recently seems to center around these important
issues of hygiene and identifiers. IMO, R6RS got this right by treating
identifiers as a completely disjoint type from symbols. I do not think we
should be conflating the two. I am glad you bring up this point, because I
do think that the conflation of symbols and identifiers in forms like the
above is just incorrect. Indeed, throughout the standard, I think you have
mentioned a few places where these issues come up. I would rather undercut
them all by saying at the outset that, when the standard talks about names
and such as it does here, an identifier is meant, and not symbols. That
means that you can't do symbolic comparison here.
Aaron W. Hsu
--
Programming is just another word for the lost art of thinking.
_______________________________________________
Scheme-reports mailing list
Scheme-reports@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports