<$BlogRSDUrl$>

Tuesday, February 17, 2004

literal expressions and external representation

part 4.1.2 of the spec discusses the quote operator. It says," (quote <datum>) evalutates to <datum>. <Datum> may be any external representation of a Scheme object." Hrm, so what's an external representation? It's a "sequence of characters", like "28" or "(8 13)". These sequences of characters "may be written in a program to obtain the corresponding object", as in the use of quote above.

so the question from before was something like, if you evaluate a quoted expression do you get back a something other than the expression itself -- a 'literal expression' type thing? according to the above, the answer is /yes/, what you get back is the external representation of the thing.

oddness. so, when does an external representation become an internal one? interpreter I - IV converted external representations to internal ones at the time of parsing.. (that's just what parsing was for). Evaluating a quoted expression, in those interpreters, has the effect of returning the expression itself, not the sequence of characters that make up the expression.

Ah, so maybe the spec is being murky again (that is, maybe my mind is being murky again as i read the spec) because look here, in the bit about external representations it says this, "Note that the sequence of characters "(+ 2 6)" is /not/ an external representation of the integer 8, even though it /is/ an expression evaluating to the integer 9 ..." Ah ha, so they /are/ calling the sequence of characters an expression, which means that if they say a quoted expression returns an external representation then they mean that it's exactly the same as returning the expression itself?

But wait, the above quotation from the spec continues, "... rather, it is an external representation of a three-element list, ..." Blurp.

so, my question remains,

when does an external representation become an internal one?

macros
Reading Petrofsky's article on syntax-rules and much more from the spec, it's making some sense. So, here are the two key bits from the spec on "hygienic" and "referentially transparent":
  1. If a macro transformer inserts a binding for an identifier (variable or keyword), the identifier will in effect be renamed throughout the scope to avoid conflicts with other identifiers...
  2. If a macro transformer inserts a free reference to an identifier, the reference refers to the binding that was visible where the transformer was specified, regardless of any local bindings that may surround the use of the macro
Together #1, and #2, ensure that identifiers the macro transformer spits out act like the identifiers in the macro spec, and not like any similarily named identifiers that occur around the /use/ of the macro. That is, the above rules allow you to treat the identifiers used in a macro expansion as distinct identifiers even if they share the same /external representation/ as identifiers in the region of the macro use (that's #1), and the scope rules used to resolve an expansion-produced identifier are such that if a binding to it (the distinct identifier from #1) isn't found in the current region, we look next in the region of the macro spec that produced it (that's #2).

He paused for a moment's reflection.

"Tricky," he said finally.


0 Comments:

This page is powered by Blogger. Isn't yours?