Re: [Scheme-reports] [wg2] in support of single-arity procedural syntax transformers

[Alaric Snell-Pym <alaric@x>]

On 05/12/11 11:39, Andy Wingo wrote:
> Hi Alaric,
>
> On Thu 12 May 2011 11:27, Alaric Snell-Pym <alaric@x> writes:
>
>> I think Andy's opined in the past that using weak maps to [map source
>> information to code] is insufficient, requiring explicit syntax
>> objects rather than just sexprs.
>>
>> Andy, is that a correct interpretation, and if so, can you explain that?
>
> Yes, I've said that, though it does seem a minor point.  (A herring-tail
> wagging a dog?)  Basically the deal is that in an expression like:
>
> 0:  (+ 37
> 1:     foo
> 2:     bar
> 3:     baz)
>
> where `bar' is unbound, you want to say "line 2 column 4: `bar' is
> unbound", rather than attributing the error to (say) line 0.  I keep
> using Racket as the example here, because I think they do it very well,
> even highlighting the expression precisely in their editor.
>
> But this sort of information is difficult to propagate through an
> expander if you don't wrap your s-expressions in some other data
> structure, like a syntax object.

However, that s-expression is five cons cells - each element of the list
gets its own cons cell, that could carry the source information, rather
than the actual symbol or number or whatever within.

EXPERIENCED IMPLEMENTORS: Is that enough? Do any useful cases slip
through the cracks there? Like, vector literals? Would we need to store
a parallel vector for each vector (linked to it from the weakmap) with
the information about where each of its elements came from? How about
struct literals, if your system has them?

> Now, to actually get such source information in the first place, you
> need a `read-syntax':
>
>   http://docs.racket-lang.org/reference/Reading.html?q=read-stx#(def._((quote._~23~25kernel)._read-syntax))

I feel an immediate concern, though, about having some s-expressions
wrapped in magic objects that need to be unpeeled. syntax-case is a
monolithic hybrid of a perfectly good pattern-matching library and
autoamtic unwrapping of such syntax objects so they can match patterns
correctly, and then re-wrap them in newly created output syntax, so
thereby partly presenting the illusion that the wrapping and unwrapping
isn't happening... and that triggers a "not jewel like" ache in my joints.

But I also see that weak maps have their own complexities (especially my
"doesn't work on symbols" workaround hack above, and the danger of
accidentally losing the information by innocently doing something that
re-conses the same cons cell... let alone REVERSEing a list).

But what happens if you try to REVERSE a syntax-object wrapping a list?
You can't - it's not even a list (the cons cells are wrapped). As soon
as you create this ugly parallel type hierarchy, you need duplicates of
all the useful tools. It's as bad as invoking monads in Haskell,
whereupon every higher-order function needs a new monadified version. Ugh!

What other tricks are there, besides weak maps and syntax objects?
Perhaps implementations need to have mechanisms to create symbols and
numbers and other such literals with identities (complicating the
definition of eq?, mind). CL's namespaces sort of worked like this for
symbols; the "same-looking" symbol in different namespaces had a
different identity. Perhaps shadowed binding's symbolic names shouldn't
be EQ? to each other even though the symbol's text is the same (although
this will confuse users sometimes). I can see how that would work for
symbols, but it doesn't really extend to numbers and #t and so on.

Comments? Thoughts?

> But that need not be specified.

It'd be a shame if it weren't, though, IMHO, as then a significant part
of the system would be murkily unavailable to portable code. Like,
building your own REPLs. What if I want to write something to provide a
REPL with decent error reporting over a TCP socket or something? What if
your source code comes from a database of pre-parsed s-expressions that
you serialise using a snazzy object persistence layer? You'd want error
messages to point back to that, rather than to some random s-expression
text a user typed in ages ago when ENTERING it into the database. I
think that the mechanism used to attach metadata to s-expressions needs
to be accessible to portable code (even if it's just specified in WG2,
with WG1 scheme allowing, but not requiring, such a metadata mechanism).

> Andy

ABS

--
Alaric Snell-Pym
http://www.snell-pym.org.uk/alaric/

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