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:

  (define-syntax swap!
    (er-macro-transformer
      (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
> wrapped).

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
non-existent `vector-reverse'.

> As soon as you create this ugly parallel type hierarchy,

FUD.

> you need duplicates of all the useful tools.

FUD FUD.

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?

Wrong:

  (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!

More FUD.

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
> identity.

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
Scheme-reports@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports