On Sat, May 30, 2009 at 04:50:02PM -0500, John M. Dlugosz wrote:
> Note that ≥ and ≤ are "bidi mirroring" characters in the Unicode  
> Properties.  So if someone were crazy enough to use them as brackets,  
> then the digraph equivalent should work as well, right?

No, they'd only function as digraphs in the infix syntactic category.
Bracketing chars are outside of any such category.  Perl 6 is very
careful to recognize macro-like things only where they would make
sense for their particular category.  That's part of the magic of
STD, that it generates different lexers at each choice point in
the grammar, and does so just-in-time, based on the current language

Now, within a particular syntactic category you can have conflicts,
and with other categories that are ORed in to it; for example,
prefixes share LTM space with terms and circumfixes, for instance.
So we do have to be a little careful about defining other termish
things that start '<<' though, since '«'can introduce a term.
That's one of the reasons heredocs don't use that notation any more.
But that only interferes with spots where a term is expected.

There is a corresponding conflict at postfix position, but the two are
causally unrelated.  I hesitate to call them digraphs even, since to
me that kinda implies they're translated without regard to context,
as by a preprocessor, and they're not.

> I'm more interested in making sure that someone _can_ easily define ℝ as  
> a type name than in providing that by default.

Indeed, getting "close enough" is one of the underlying design themes
of Perl 6.  As to whether we're close to do the operator aliasing in
a mostly digraphic fashion, I'm not sure.  Currently a macro for an
infix would be given the AST of the left argument to play with, and
the opportunity to influence the parse of its right argument.  This is
overkill for a mere alias.  We may need to distingish single-token
substitution macros from macros that govern the ASTs around them in
order to make such operator canonicalization painless, I think.


Reply via email to