See below for the S06 section I'm referring to.
I'm wondering how we should be reading the description of user-defined
operators. For example, "sub infix:<(c)>" doesn't describe
the precedence level of this new op, so how is it parsed? Is there a
default?
Right now, this doesn't work as I'd expect in Rakudo for all categories. For
example:
$ ./perl6 -e 'sub infix:<i> ($a,$b) { return $a+($b*1i); } ; say 3 i 2'
3 + 2i
Correct.
$ ./perl6 -e 'sub term:<i> () { return 1i; } ; say i'
error:imcc:syntax error, unexpected '\n'
in file 'EVAL_1' line 105914178
Eh? What newline? And line 105914178?
OK, so that's a bug, but the question is, should I expect it to work?
Things get a bit more strange when I try to wrap my head around macros. From
the example:
macro circumfix:«<!-- -->» ($text) is parsed / .*? / { "" }
OK, so when a circumfix would be allowed (any expression?) we accept <<!--
-->> and the result is an empty string which is... now, follow me here,
'cause I get lost myself... re-parsed within the context of what we've
already parsed, and its resulting AST is then returned as if via "make".
But doesn't that mean that in order to chain two comments, I would need
something to join the new null expressions, e.g.:
<!-- --> ; <!-- -->
In a way, I'd find that comforting. It's not as useful for creating comments
as I'd have wanted, but at least it behaves like any other circumfix:
category operator.
Along the lines of macros, am I correct in my assumption that a macro will
either exist within a grammatical category that it names, or will be
evaluated as an expression, just like a subroutine invocation? That is,
there will be no way to do something like:
macro endofline() { ";" }
since there's no way to change the state of the parser that invoked the
macro, other than to return an AST.
I think there's also a bug in the examples when it comes to ±. That can be a
method, sure, that makes sense, but in which case I don't think it should be
taking a parameter. Wouldn't that be:
method prefix:<±> (--> Num) { return +self.myintvalue | -self.myintvalue
}
So that it would be used like so:
my $x = MyInt.new(:myintvalue(5));
say ±$x;
which I would expect to yield:
any(5, -5)
>From S06:
------------
Operators are just subroutines with special names and scoping. An operator
name consists of a grammatical category name followed by a single colon
followed by an operator name specified as if it were a one or more strings.
So any of these indicates the same binary addition operator:
infix:<+>
infix:«+»
infix:<<+>>
infix:['+']
infix:["+"]
This seems to imply that we can define our own operators.
Use the & sigil just as you would on ordinary subs.
Unary operators are defined as prefix or postfix:
sub prefix:<OPNAME> ($operand) {...}
sub postfix:<OPNAME> ($operand) {...}
Binary operators are defined as infix:
sub infix:<OPNAME> ($leftop, $rightop) {...}
Bracketing operators are defined as circumfix where a term is expected or
postcircumfix where a postfix is expected. A two-element slice containing
the leading and trailing delimiters is the name of the operator.
sub circumfix:<LEFTDELIM RIGHTDELIM> ($contents) {...}
sub circumfix:['LEFTDELIM','RIGHTDELIM'] ($contents) {...}
Contrary to Apocalypse 6, there is no longer any rule about splitting
an even number of characters. You must use a two-element slice. Such names
are canonicalized to a single form within the symbol table, so you must use
the canonical name if you wish to subscript the symbol table directly (as in
PKG::{'infix:<+>'}). Otherwise any form will do. (Symbolic references do not
count as direct subscripts since they go through a parsing process.) The
canonical form always uses angle brackets and a single space between slice
elements. The elements are escaped on brackets, so
PKG::circumfix:['<','>']is canonicalized to PKG::{'circumfix:<\<
\>>'}, and decanonicalizing may always be done left-to-right.
Operator names can be any sequence of non-whitespace characters including
Unicode characters. For example:
sub infix:<(c)> ($text, $owner) { return $text but Copyright($owner) }
method prefix:<±> (Num $x --> Num) { return +$x | -$x }
multi sub postfix:<!> (Int $n) { $n < 2 ?? 1 !! $n*($n-1)! }
macro circumfix:«<!-- -->» ($text) is parsed / .*? / { "" }
my $document = $text (c) $me;
my $tolerance = ±7!;
<!-- This is now a comment -->
Whitespace may never be part of the name (except as separator within a
<...> or «...» slice subscript, as in the example above).
A null operator name does not define a null or whitespace operator, but a
default matching subrule for that syntactic category, which is useful when
there is no fixed string that can be recognized, such as tokens beginning
with digits. Such an operator *must* supply an is parsed trait. The Perl
grammar uses a default subrule for the :1st, :2nd, :3rd, etc. regex
modifiers, something like this:
sub regex_mod_external:<> ($x) is parsed(token { \d+[st|nd|rd|th] }) {...}
Such default rules are attempted in the order declared. (They always
follow any rules with a known prefix, by the longest-token-first rule.)
Although the name of an operator can be installed into any package or
lexical namespace, the syntactic effects of an operator declaration are
always lexically scoped. Operators other than the standard ones should not
be installed into the * namespace. Always use exportation to make
non-standard syntax available to other scopes.
--
Aaron Sherman
Email or GTalk: a...@ajs.com
http://www.ajs.com/~ajs
