Re: [svn:perl6-synopsis] r14510 - doc/trunk/design/syn
On Fri, Feb 15, 2008 at 03:59:28PM -0800, Jonathan Lang wrote:
: > +Despite the appearance as a subscripting form, these names are resolved
: > +not at run time but at compile time. The pseudo-subscripts need not
: > +be simple scalars. These are extended with the same two-element list:
: > +
: > +infix:
: > +infix:['??','!!']
:
: Huh. I thought that multiple elements were only permitted in
: circumfix and postcircumfix, and that even there you had to use
: precisely two. Not that I'm complaining; but if this is a change of
: policy, we should consider the ramifications:
There are no such ramifications. These are merely names. The parsing
depends on the parts of the name only if the parsing rule chooses to
use them. In the STD grammar all such rules parse their pieces
explicitly, not by reference to the name.
: An infix operator with multiple delimiters must be list-associative;
: it must use the delimiters in order; and it must have one fewer
: delimiter than the number of positional parameters in the signature.
: Exception: if the signature includes a slurpy array, one more
: delimiter can be added to separate the slurped arguments. An infix
: operator with one delimiter is under none of these restrictions.
:
: A circumfix or postcircumfix operator can have three or more
: delimiters. In this case, the first and last delimiters get treated
: as the bracketing characters, and the bracketed contents get parsed
: using the remaining delimiter(s) as per the rules for infix operators
: (trimming off the leading parameter, in the case of postcircumfix
: operators).
:
: The only catch with this is that Conditional Operator Precedence is
: left-associative, not list associative. List-associativity would
: probably work as well or better for infix:; but this precedence
: level also includes ff and fff.
Indeed, going down this path opens several cans of worms. This is
better solved explicitly from within the parsing rule itself in the
rare cases that you want to anything so complicated. Boiled down,
the rule for the standard conditional operator is just:
token { '??' '!!' }
and the allowed precedence in the middle is both evident and succinct.
Normal parens are parsed as:
token { '(' ')' }
I see virtually no need for Another Way To Do It in this case. It would
only contribute to the befuddlement of the masses.
Larry
Re: [svn:perl6-synopsis] r14510 - doc/trunk/design/syn
> +Despite the appearance as a subscripting form, these names are resolved > +not at run time but at compile time. The pseudo-subscripts need not > +be simple scalars. These are extended with the same two-element list: > + > +infix: > +infix:['??','!!'] Huh. I thought that multiple elements were only permitted in circumfix and postcircumfix, and that even there you had to use precisely two. Not that I'm complaining; but if this is a change of policy, we should consider the ramifications: An infix operator with multiple delimiters must be list-associative; it must use the delimiters in order; and it must have one fewer delimiter than the number of positional parameters in the signature. Exception: if the signature includes a slurpy array, one more delimiter can be added to separate the slurped arguments. An infix operator with one delimiter is under none of these restrictions. A circumfix or postcircumfix operator can have three or more delimiters. In this case, the first and last delimiters get treated as the bracketing characters, and the bracketed contents get parsed using the remaining delimiter(s) as per the rules for infix operators (trimming off the leading parameter, in the case of postcircumfix operators). The only catch with this is that Conditional Operator Precedence is left-associative, not list associative. List-associativity would probably work as well or better for infix:; but this precedence level also includes ff and fff. -- Jonathan "Dataweaver" Lang
[svn:perl6-synopsis] r14510 - doc/trunk/design/syn
Author: larry Date: Fri Feb 15 14:54:28 2008 New Revision: 14510 Modified: doc/trunk/design/syn/S02.pod Log: Clarification of identifier extensions requested by thom++ Modified: doc/trunk/design/syn/S02.pod == --- doc/trunk/design/syn/S02.pod(original) +++ doc/trunk/design/syn/S02.podFri Feb 15 14:54:28 2008 @@ -12,9 +12,9 @@ Maintainer: Larry Wall <[EMAIL PROTECTED]> Date: 10 Aug 2004 - Last Modified: 8 Feb 2008 + Last Modified: 15 Feb 2008 Number: 2 - Version: 128 + Version: 129 This document summarizes Apocalypse 2, which covers small-scale lexical items and typological issues. (These Synopses also contain @@ -722,7 +722,7 @@ For graphemes that have no precomposed form, a temporary private id should be assigned that uniquely identifies the grapheme. -If such identifiers are assigned consistently thoughout the process, +If such ids are assigned consistently thoughout the process, comparison of two graphemes is no more difficult than the comparison of two integers, and comparison of base characters no more difficult than a direct lookup into the id-to-NFD table. @@ -1989,6 +1989,54 @@ explicit consent of all parties. No magical syntax at a distance. Consent of the governed, and all that. +=item * + +It is often convenient to have names that contain arbitrary characters +or other data structures. Typically these uses involve situations +where a set of entities shares a common "short" name, but still needs +for each of its elements to be identifiable individually. For +example, you might use a module whose short name is C, +but the complete long name of a module includes its version, naming +authority, and perhaps even its source language. Similarly, +sets of operators work together in various syntactic categories +with names like C, C, C, etc. The long +names of these operators, however, often contain characters that +are excluded from ordinary identifiers. + +For all such uses, an identifier followed by a subscript-like adverbial +form (see below) is considered an I: + +infix:<+># the official name of the operator in $a + $b +infix:<*># the official name of the operator in $a * $b +infix:«<=» # the official name of the operator in $a <= $b +prefix:<+> # the official name of the operator in +$a +postfix:<--> # the official name of the operator in $a-- + +This name is to be thought of semantically, not syntactically. That is, +the bracketing characters used do not count as part of the name; only +the quoted data matters. These are all the same name: + +infix:<+> +infix:<<+>> +infix:«+» +infix:['+'] + +Despite the appearance as a subscripting form, these names are resolved +not at run time but at compile time. The pseudo-subscripts need not +be simple scalars. These are extended with the same two-element list: + +infix: +infix:['??','!!'] + +An identifier may be extended with multiple named identifier +extensions, in which case the names matter but their order does not. +These name the same module: + +use ThatModule:ver<2.7.18.28.18>:auth +use ThatModule:auth:ver<2.7.18.28.18> + +Adverbial syntax will be described more fully later. + =back =head1 Literals
