> On Sep 24, 2016, at 12:46 PM, William G Hatch <will...@hatch.uno> wrote:
> Additionally, I've long wanted more types of parens in Racket. I
> haven't really known what I would do with them -- I use Racket's
> conventions for () and [], and have my own loose convention for {}. But
> after seeing Jay McCarthy's wonderful talk on Remix, I am now blatantly
> stealing his idea of wrapping different paren types with a
> macro-dispatchable symbol.
>
> So udelim has functions for extending readtables to have more parens and
> balanced string delimiters, optionally wrapped up a-la Remix. It also
> has a stx-string->port function for convenience in making macros that
> read an alternate syntax with those nestable strings. It has a
> metalanguage with some delimiters auto-enabled: «» (guillemets, used as
> quotes in many European languages) as nestable, non-escaping quotes, ｢｣
> likewise but wrapped so ｢foo bar｣ reads as (#%cjk-corner-quotes "foo
> bar"), and several unicode paren types (﴾﴿, ⦓⦔, ⦕⦖, 🌜🌛, ...) wrapped
> with a starter symbol as well.
While I like the idea of more types of parens for meaning different things, I'm
not sure whether having a #%cjk-corner-quotes -ish macro *expected to be
defined* for every one of them is the best way to do it, or whether we should
be trying to think of a better way to introduce the distinction.
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.
Now the problem with 'paren-shape is that everything ignores it. But that could
easily change if you had a syntax-parse pattern to check the property for you.
But a different problem occurs with the remix #%brackets convention. A form
like [a b c] would match the pattern (a ...), which doesn't seem like an ideal
default. With a 'paren-shape syntax property and a syntax-parse pattern
expander, the pattern (a ...) could mean only match syntax lists with a
'paren-shape property of #\( .
Are there any alternative ways to solve these problems?
Alex Knauth
--
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.
