On Thu, 05 May 2011 11:52:56 -0400, Andre van Tonder <[email protected]>  
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
[email protected]
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports

Reply via email to