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 definition. 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. Larry
