> To try and make it easier to pick (ASCII) operators, a simple table of > what's given away and what's available. Please let me know if there are > any mistakes.
Thanks! Here's an annotated bit for each ?.
> If anyone knows how to fill in the "???" parts, be my guest! > ! not none() ???
Nope. In order to create those, you just need to say none(). There is no operator form.
> !! AVAILABLE? AVAILABLE?
Given prefix:<?>, I suppose that is available.
> @@ AVAILABLE? AVAILABLE
Yep.
> $$ AVAILABLE? AVAILABLE
Nope. Not in term position. I hardly think it would be a good idea to make an operator out of it (or even a single $), however.
> % hash mod > %% AVAILABLE? AVAILABLE?
Yes.
> \\ AVAILABLE? AVAILABLE
Uh huh.
> == AVAILABLE? num eq
Fortunately yes. Let's keep it that way.
> --> AVAILABLE AVAILABLE?
I suppose it is. That would destroy Damian's favorite little idiom:
while ($x --> 0) {...}
But I don't think that's a huge loss. :-)
> <-> don't touch it, I'm going to use this for -> is rw :)
In operator position. In term position it is a single-quoted -.
> ?? AVAILABLE? ternary
Yep.
> :: namespace ternary
That's "class sigil" in term position. Separating namespaces never have preceding whitespace, so they're always part of some larger term.
> \w+ infix only > x passive repeat > xx passive repeat > X active repeat ??? > XX active repeat ???
Those two haven't been blessed, and, though I don't have the message, I think I remember Larry being a little hesitant about adding those.
> Y zip() > many still available!
> With double characters (like ~~), "AVAILABLE?" means that if we start > using that, stacking of the single thing will start requiring > whitespace, as with = and == in $foo = =$fh)
> "ws?" means that whitespace may be needed for disambiguation.
> I left out colon and semicolon because they're too special to fit in a > term|op table. I think it's more than safe to assume they're taken :)
Um, yes.
> <> is more flexible than {}, [] and () because it's a quoting operator > (the inside is not an expression).
> I think it's best to ignore entirely the fact that we can use more > triple character proper operators :)
Only the triple-questionmarks were meant as questions. I should have picked a better meta-operator for AVAILABLE?. But apparently, even though I didn't mean to ask so many questions, there still are answers I hadn't thought about.
Thanks for your detailed reply!
> > ! not none() ??? > Nope. In order to create those, you just need to say none(). There > is no operator form.
Do we have postfix ! for factorials, or is it available?
> > $$ AVAILABLE? AVAILABLE > Nope. Not in term position. I hardly think it would be a good idea > to make an operator out of it (or even a single $), however.
Why would a single $ be a bad operator? We already have the single % for mod, and that works well. I think @ and $ are perfect candidates for infix operators.
> I suppose it is. That would destroy Damian's favorite little idiom: > while ($x --> 0) {...}
aww :)
> That's "class sigil" in term position. Separating namespaces never > have preceding whitespace, so they're always part of some larger term.
Is there any important difference between "namespace" and "class" in Perl 6? Do they share the same, ehm, namespace? (classspace?)
To try and make it easier to pick (ASCII) operators, a simple table of what's given away and what's available. Please let me know if there are any mistakes.
If anyone knows how to fill in the "???" parts, be my guest!
\W+ Term (pre|circ) Operator (post|in) ` AVAILABLE AVAILABLE `` AVAILABLE AVAILABLE ~ stringy concat ~... string bitops ~~ AVAILABLE? smart match ! not none() ??? != ! == !~ ! ~~ !! AVAILABLE? AVAILABLE? @ array AVAILABLE @@ AVAILABLE? AVAILABLE # comment comment $ scalar AVAILABLE $$ AVAILABLE? AVAILABLE % hash mod %% AVAILABLE? AVAILABLE? ^ AVAILABLE one() ^^ AVAILABLE xor & sub all() && (clash) and * splat multiply ** steam roller power () group sub (deref+)call (no ws) ()? (clash) AVAILABLE (ws) \ ref AVAILABLE \\ AVAILABLE? AVAILABLE | AVAILABLE any() || AVAILABLE or [] aref|reduce array (deref+)subscript (no ws) []? (clash) AVAILABLE (ws) {} href|closure hash (deref+)subscript (no ws) {}? (clash) AVAILABLE (ws) + numeric add +... numeric bitops ++ preinc postinc = iterate assign => AVAILABLE pair == AVAILABLE? num eq ==> pipe pipe - 0- substract -> sub sub -- predec postdec --> AVAILABLE AVAILABLE? '' q AVAILABLE ('|'') "" qq AVAILABLE ("|"") , ??? list sep ,, ??? ??? <> qw hash (deref+)subscript (no ws) <>? (clash) AVAILABLE (ws) < (clash) less-than (ws) <= (clash) le (ws) <== pipe pipe <-> don't touch it, I'm going to use this for -> is rw :) > AVAILABLE (ws) greater-than >= AVAILABLE (ws) ge (ws?) <<>> qw hash (deref+)subscript (no ws) <<[>>]? (clash) AVAILABLE (ws) << hyper hyper >> hyper hyper . $_. (deref+)subscript|method call / (clash) divide // m// defined-or ? true AVAILABLE ?... boolean bitops ?? AVAILABLE? ternary :: namespace ternary
\w+ infix only x passive repeat xx passive repeat X active repeat ??? XX active repeat ??? Y zip() many still available!
With double characters (like ~~), "AVAILABLE?" means that if we start using that, stacking of the single thing will start requiring whitespace, as with = and == in $foo = =$fh)
"ws?" means that whitespace may be needed for disambiguation.
I left out colon and semicolon because they're too special to fit in a term|op table. I think it's more than safe to assume they're taken :)
<> is more flexible than {}, [] and () because it's a quoting operator (the inside is not an expression).
I think it's best to ignore entirely the fact that we can use more triple character proper operators :)
Patrick R. Michaud skribis 2005-05-06 12:20 (-0500):
> Ummm, what about C<not> and C<true> ?
I'm sticking to non-words here, as I mentally parse not and true as single-arg subs, single-arg subs as unary operators, etcetera. I can't help it, but I have absolutely no idea how to determine the difference. Is it &prefix:<not> or just ¬? I have no idea. I do know that it's &infix:<x>, not &x.
> Because we're marking all of our singular nouns with $, and you have > to admit, the $ sigil in perl code is much more common than @ and %. > What good is a noun marker if you mark some of your verbs with it too?
On Fri, May 06, 2005 at 06:24:00PM +0200, Juerd wrote: > To try and make it easier to pick (ASCII) operators, a simple table of > what's given away and what's available. Please let me know if there are > any mistakes.
> If anyone knows how to fill in the "???" parts, be my guest! > [...]
> Luke Palmer skribis 2005-05-06 10:43 (-0600): > > > ! not none() ??? > > Nope. In order to create those, you just need to say none(). There > > is no operator form.
> Do we have postfix ! for factorials, or is it available?
No, it's available. What would we use to demonstrate how to write postfix operators (not to mention recursive functions) if we made that standard?
> > > $$ AVAILABLE? AVAILABLE > > Nope. Not in term position. I hardly think it would be a good idea > > to make an operator out of it (or even a single $), however.
> Why would a single $ be a bad operator? We already have the single % for > mod, and that works well. I think @ and $ are perfect candidates for > infix operators.
Because we're marking all of our singular nouns with $, and you have to admit, the $ sigil in perl code is much more common than @ and %. What good is a noun marker if you mark some of your verbs with it too?
Luke
> > That's "class sigil" in term position. Separating namespaces never > > have preceding whitespace, so they're always part of some larger term.
> Is there any important difference between "namespace" and "class" in > Perl 6? Do they share the same, ehm, namespace? (classspace?)
Just making sure you weren't considering the :: in $Foo::Bar to be an operator. There is a difference between class and namespace in that a class is a type and a namespace isn't. But I think you mark them both with the :: sigil in this case.
> I'm sticking to non-words here, as I mentally parse not and true as > single-arg subs, single-arg subs as unary operators, etcetera. I can't > help it, but I have absolutely no idea how to determine the difference. > Is it &prefix:<not> or just ¬? I have no idea. I do know that it's > &infix:<x>, not &x.
Though, P6 mayl give us the ability to create circumfix operators (as seen in the entire reduce thread). I think that syntax will also allow for functions to be parsed as infix operators, right?
On Fri, May 06, 2005 at 01:31:43PM -0400, Rob Kinyon wrote:
: > I'm sticking to non-words here, as I mentally parse not and true as : > single-arg subs, single-arg subs as unary operators, etcetera. I can't : > help it, but I have absolutely no idea how to determine the difference. : > Is it &prefix:<not> or just ¬? I have no idea. I do know that it's : > &infix:<x>, not &x. : : Though, P6 mayl give us the ability to create circumfix operators (as : seen in the entire reduce thread). I think that syntax will also allow : for functions to be parsed as infix operators, right?
Sure, but in that case we usually call them methods. :-)
On Fri, May 06, 2005 at 06:49:44PM +0200, Juerd wrote:
: Luke Palmer skribis 2005-05-06 10:43 (-0600): : > Why the %!@ would you ignore that!? :-) : : I hate my brain. Now I wonder if Bool.does(Hash). Does it? :)
Any Object does Hash, and treats any argumentless method as a potential hash key. So Bool is likely to recognize $boolean<bit> and return 0 or 1, possibly disguised as Bool::true or Bool::false. On the other hand, a low-level bool type might not choose to box itself to Bool just so you can treat it as a hash and get the low level value back out. Then again, it might. :-)
On Fri, May 06, 2005 at 11:25:31AM -0700, Larry Wall wrote:
: Any Object does Hash, and treats any argumentless method as a potential : hash key.
I should also point out that the main reason for this is to allow easier translation of Perl 5 idioms to Perl 6 without having to guess whether $foo contains an unblessed hash ref or a real Perl 6 object. We're not actually recommending peole use hash notation to call attribute methods.
|foo| for ... { while ... { ...; next foo if ...; } }
It'll confuse the heck out of Ruby coders, but I do like this syntax. It makes labels stand out, as was one of the requirements, and it puts a little less strain on the colon.
(Now, if we really want to bug Rubyfolk, we could make labels per block instead of per statement, and put them inside the curlies:
for ... { |foo| while ... { ...; next foo if ...; } }
On Fri, May 06, 2005 at 10:43:07AM -0600, Luke Palmer wrote:
: > :: namespace ternary : : That's "class sigil" in term position. Separating namespaces never : have preceding whitespace, so they're always part of some larger term.
Really more like a package sigil, which can be used as a module, class, role, or type sigil.
: > X active repeat ??? : > XX active repeat ??? : : Those two haven't been blessed, and, though I don't have the message, : I think I remember Larry being a little hesitant about adding those.
The question is whether to treat the left arg the same way we treat attribute defaults, with one free closure call. We could say that
{ rand 10 } x 100 { rand 10 } xx 100
should just automatically call the closure on the left repeatedly. In the rare, rare case that you want to actually replicate a closure, you'd have to say
{ { rand 10 } } x 100 { { rand 10 } } xx 100
Then we save two operators. We could also pass the counter in as $_:
{ foo($_) } xx 100; # call foo(0), foo(1)...foo(99)
On Fri, May 06, 2005 at 06:24:00PM +0200, Juerd wrote:
: {} href|closure hash (deref+)subscript (no ws) : {}? (clash) AVAILABLE (ws)
s/AVAILABLE/statement block/
Actually, I'd try to find a way to combine all the paired ws-dependent entries onto the same line, since splitting them to separate lines induces a fake clash. Maybe
> |foo| for ... { > while ... { > ...; > next foo if ...; > } > }
> It'll confuse the heck out of Ruby coders, but I do like this syntax. It > makes labels stand out, as was one of the requirements, and it puts a > little less strain on the colon.
> (Now, if we really want to bug Rubyfolk, we could make labels per block > instead of per statement, and put them inside the curlies:
> for ... { |foo| > while ... { > ...; > next foo if ...; > } > }
> *evil grin*)
Actually if we define |...| at all, I'd prefer it mean abs(), its usual mathmatical meaning.
On Sat, 07 May 2005 01:47:08 -0400, Matt Creenan <m...@weakmind.org> wrote:
> So here's some random ideas that probably make no sense ($ can be > optional.. don't know)
> *snip*
That brings me to another idea. Is $_ as an array used? @_?
This relates back to the discussion on topics. Could be use @_ as an array of topics, or was that already proposed?
So you could reference @_ as an indexed array, @_[0] being the current topic, or maybe @_[1] and having @_[0] as the number of topics. Then you could reference %_ as a hashed array, where you give the blockname to get that blocks topic/invocant.
Let's assume that naming blocks was done like such:
block1 -- for 1..5 { block2 -- for 1..3 { say @_[1] ~ @_[2]; } }
or
block1 -- for 1..5 { block2 -- for 1..3 { say %_<block2> ~ %_<block1>; } }
I can't remember if barewords are allowed, so pretend I have '' around those blocknames for the hashes if they aren't :)
Also, the block names could then be used for next/last/continue/whatever.
> Actually if we define |...| at all, I'd prefer it mean abs(), its usual > mathmatical meaning.
No. We can't just use circumfix |...| with arbitrary expressions in it, because | is taken as an infix operator. It has to be quoteish (like <> (this is why there can be infix < and >, even though <> is taken)), or you end up with ugly parens. Only mirrored sets are useful for arbitrary expressions, the same thing left and right makes things very hard. But for quoteish operators, that's no problem: '', "", //, and perhaps ||. Labels would also specifically be limited to \w+.
And personally I could not care any less about the mathematical meaning. I have never cared about that with other operators. We don't have << and
>> to mean much less than and much greater than, do we? Should we?
> I thought about $blockname <= { ... }, but <= is obviously taken, as is <== > $blockname <=: for 1..5 { > $blockname :=> for 1..5 { > } $blockname; > } <=: $blockname; > } $blockname; > $blockname for 1..5 { > $blockname -- for 1..5 { > } -- $blockname; > } $blockname; > $blockname @ for 1..5 { # Yeah I know @ is probably impossible > } @ $blockname; > $blockname ??? for 1..5 {
IMO, all of these are worse than "label:". And most of your syntaxes limit labels to blocks, while currently they can be placed before any statement, and it has been said that this behaviour is preferred.
> The question is whether to treat the left arg the same way we treat > attribute defaults, with one free closure call. We could say that
> { rand 10 } x 100 > { rand 10 } xx 100
> should just automatically call the closure on the left repeatedly. In > the rare, rare case that you want to actually replicate a closure, you'd > have to say
> { { rand 10 } } x 100 > { { rand 10 } } xx 100
But we also have to remember that, given:
my @codes = { { rand 10 } } xx 100; say @codes[0] == @codes[1]; # 0
You're not duplicating one closure as you are with:
my @others = { rand 10 } xx 100;
Without the closure semantics of xx. If you made @codes[0] do some role, it would only apply to @codes[0], but if you made @others[0] do some role, it would apply to every closure in @others.
On Sat, May 07, 2005 at 02:23:15PM +0200, Juerd wrote:
: Matt Creenan skribis 2005-05-07 1:47 (-0400): : > I thought about $blockname <= { ... }, but <= is obviously taken, as is <== : > $blockname <=: for 1..5 { : > $blockname :=> for 1..5 { : > } $blockname; : > } <=: $blockname; : > } $blockname; : > $blockname for 1..5 { : > $blockname -- for 1..5 { : > } -- $blockname; : > } $blockname; : > $blockname @ for 1..5 { # Yeah I know @ is probably impossible : > } @ $blockname; : > $blockname ??? for 1..5 { : : IMO, all of these are worse than "label:". And most of your syntaxes : limit labels to blocks, while currently they can be placed before any : statement, and it has been said that this behaviour is preferred.
Labels will remain on statements. However, you can sneak a statement (including its label) into the middle of an expression by using "do":
$outer = do LINE: for =$IN {...; $inner ==> leave LINE }
Note that "do" no longer requires braces unless you wish to continue the expression after the do. Which we can get away with because do-SUB is gone and do-File is renamed to evalfile or some such. Maybe it can be demoted to
eval requirefinder($filename);
since we're trying to discourage use of do-File anyway, and we can probably abstract out the parts that require and do-File have in common.
