[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Scheme-reports] [wg2] in support of single-arity procedural syntax transformers
6 hours ago, Alaric Snell-Pym wrote:
> 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
FUD, FUD, FUD.
> 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.
See my previous reply. The jewel is in the type and the simplicitly
that comes out of sticking to it.
Personally, I look at:
(lambda (form rename compare)
(let ((a (cadr form))
(b (caddr form)))
`(,(rename 'let) ((,(rename 'value) ,a))
(,(rename 'set!) ,a ,b)
(,(rename 'set!) ,b ,(rename 'value)))))))
and I see no jewels.
> 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
Right, you need a new type for the extra information. Obviously, had
reversing a syntax object holding a list been a popular use case, it
would have been trivial to add a `reverse-syntax'. Same as the
> As soon as you create this ugly parallel type hierarchy,
> you need duplicates of all the useful tools.
Just look at the racket system (which you refer to implcitly by
talking about wrapped lists).
To give you a hint, look at the ugly parallel type that vectors make
-- you need to duplicate all the useful tools -- right?
(define vector-reverse (compose list->vector reverse vector->list))
> It's as bad as invoking monads in Haskell, whereupon every
> higher-order function needs a new monadified version. Ugh!
The syntax case extension is simply a new type -- nothing more than
that. Comparing that to the changes that monads require in programs
makes no sense. (Not to mention that the haskell claim is outright
false -- you certainly don't need new versions for every HO function,
or even for many of them.)
> 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).
Note how this goes in line with my earlier post: you're now going out
of your way to find a solution that will keep the *illusion* that your
syntax is "just S-expressions".
And BTW, my use of "illusion" was very intentional there -- weak hash
tables are often used to support such illusions, and I've used them in
plenty of cases. But they're as useful as the "all your data are
sexprs" feature -- it's useful to slap up something quickly, and as
soon as the code gets a little more substantial switching to structs
is *way* better. In the same way, weak hash tables should be dumped
for a new type when they're used in a more substantial way. Using
them for a syntax system is definitely substantial.
> CL's namespaces sort of worked like this for symbols; the
> "same-looking" symbol in different namespaces had a different
No, that's very different.
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://barzilay.org/ Maze is Life!
Scheme-reports mailing list