I hate my brain. Now I wonder if Bool.does(Hash). Does it? :)
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
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 :)
Why the %!@ would you ignore that!? :-)
Luke
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?)
Thanks again.
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 :)
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.
But verbing doesn't weird language at all!
Ummm, what about C<not> and C<true> ?
Pm
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.
Luke
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?
Rob
Sure, but in that case we usually call them methods. :-)
Larry
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. :-)
Larry
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.
Larry
We can use this for labels:
|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*)
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)
Which means
@chars = { substr($x, $_, 1) } xx $x.chars;
would be a silly way to write a split ''.
Larry
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
{} href|closure hash (deref+)subscript / statement block
or some such. (But then you need to put postfix first in the heading.)
Larry
The heading uses junctions, and junctions are unordered ;)
>
> Actually if we define |...| at all, I'd prefer it mean abs(), its usual
> mathmatical meaning.
>
I agree. I think || is just confusing.
I thought about $blockname <= { ... }, but <= is obviously taken, as is <==
So here's some random ideas that probably make no sense ($ can be
optional.. don't know)
$blockname <=: for 1..5 {
...
}
$blockname :=> for 1..5 {
...
}
for 1..5 {
...
} $blockname;
for 1..5 {
...
} <=: $blockname;
$blockname for 1..5 {
...
} $blockname;
$blockname -- for 1..5 {
...
}
for 1..5 {
...
} -- $blockname;
$blockname @ for 1..5 { # Yeah I know @ is probably impossible
...
} $blockname;
for 1..5 {
...
} @ $blockname;
$blockname ■ for 1..5 {
...
}
> Juerd skribis 2005-05-06 18:24 (+0200):
>
>> | AVAILABLE any()
>
>
> We can use this for labels:
>
> |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.
>
> 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.
next block2;
Or maybe my sleeping pills are turning me insane.
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?
The default signature of subs is (*@_).
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.
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.
Luke
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.
Larry