> On Sep 25, 2016, at 3:55 AM, William G Hatch <will...@hatch.uno> wrote:
>
> On Sat, Sep 24, 2016 at 05:33:18PM -0400, Alex Knauth wrote:
>> The way racket already does this is with a 'paren-shape syntax property,
>> which you can ignore if you want to use ｢｣ as a normal visually distinctive
>> paren type *without* needing a special macro with a weird name.
>
> I hadn't thought about the 'paren-shape property. I should put that on.
> I hadn't thought as much about these paren shapes being used to be
> distinguished in other macros (eg. macro foo will do something different
> if its argument is wrapped in bold brackets or in moon faces), but had
> thought more about either just having them be normal parens or making
> them be transformers for a fancy macro shorthand - eg. 〘+ _ 3〙might be
> a shorthand lambda wrapper or something.
The usual way to do this is with #%app, but you would be right to point out
that it shouldn't be #%app's job to handle fancy lambda shorthands, and it
wouldn't work properly if it was a macro call.
Here's an idea, what if the macro expander introduced just one more #%app-like
form in front of every expression? It's called #%group here but a better name
would be better.
(+ 1 2)
--->
(#%group + 1 2)
--->
(#%app + 1 2)
--->
(#%app + (#%datum . 1) (#%datum . 2))
--->
(#%app + (quote 1) (quote 2))
The #%group macro would be able to look at the 'paren-shape property and decide
either to expand to #%app, to expand to a lambda shorthand, or delegate to some
other macro, based on which character it sees as the value of the property.
This introduces one new macro-that-needs-to-be-defined instead of the dozens of
different ones you would need for the different delimiters, but it gives the
#%group macro the power to dispatch on the 'paren-shape property of the syntax
object. This dispatching could delegate to macros like #%braces when the
'paren-shape property is #\{, giving Remix what it wants, but these
special-cases would be handled by the #%group macro at expansion time instead
of by the reader.
I think it needs to be at expansion time because otherwise {1 2 3} looks like a
4-element list before expansion. These would seem to have very weird behavior
under quote, and it will look weird to any other macro that doesn't explicitly
look for the #%braces, #%brackets, #%cjk-corner-quotes, etc. symbols.
To have add the #%group macro would require either extending the macro expander
or having the #%module-begin macro introduce it by simulating a macro expander.
I might be misunderstanding, but does Remix already do the latter?
Alex Knauth
> But at the same time, I don't
> see how matching on the 'paren-shape property is any better or worse
> than matching funky #%paren-shape lists.
>
> So... yeah. I should definitely add the 'paren-shape property, and I'll
> make that change. And I don't want all paren shapes to create a
> #%paren-shape wrapper. But I found #%braces part of Jay's talk to be
> persuasive, at least in that I definitely want it on some of my parens.
> So maybe some unicode paren turned on by #lang udelim should have the #%
> wrapper and others not.
>
> Thanks for your thoughts.
>
> William
--
You received this message because you are subscribed to the Google Groups
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
