[RFC] Perl6 HyperOperator List
Michael Lazzaro
For this version of the operator list, (since I am unsure that _every_
unary/binary op has a meaningful hyper, and some tentatively have
_two_) I have placed all of them in EXPLICITLY. Please check that I
didn't miss any, or put any in that are incorrect.
hyperoperators:
[op] - as prefix to any unary/binary operator, "vectorizes" the
operator
unary (prefix) operators (with all hyper equivs):
\ [\] - reference to
* [*] - list flattening
? [?] - force to bool context
! [!] - force to bool context, negate
not [not] - force to bool context, negate
+ [+] - force to numeric context
- [-] - force to numeric context, negate
+^ [+^] - force to numeric context, complement
~ [~] - force to string context
~^ [~^] - force to string context, complement
. [.] - method call on current topic
++ [++] - preincrement
-- [--] - predecrement
unary (postfix) operators:
++ [++] - postincrement
-- [--] - postdecrement
... [...] - [maybe] same as ..Inf
other postfix operators:
() - (when operator is expected)
[] - array access
{} - hash access
binary operators (with ALL hyper equivs!):
+ - * / % ** x xx ~ - arithmetic
+= -= *= /= %= **= x= xx= ~=
[+] [-] [*] [/] [%] [**] [x] [xx] [~] -
(hyperversions)
[+]= [-]= [*]= [/]= [%]= [**]= [x]= [xx]= [~]=
[+=] [-=] [*=] [/=] [%=] [**=] [x=] [xx=] [~=]
< > <= >= == != <=> - comparision
lt gt le ge eq ne cmp
[<] [>] [<=] [>=] [==] [!=] [<=>] - (hyperversions)
[lt] [gt] [le] [ge] [eq] [ne] [cmp]
&& || ^^ // - boolean operations
&&= ||= ^^= //=
and or xor err
[&&] [||] [^^] [//] - (hyperversions)
[&&]= [||]= [^^]= [//]=
[&&=] [||=] [^^=] [//=]
[and] [or] [xor] [err]
.& .| .^ << >> - bitwise (integer)
operations
.&= .|= .^= <<= >>=
[.&] [.|] [.^] [<<] [>>] - (hyperversions)
[.&]= [.|]= [.^]= [<<]= [>>]=
[.&=] [.|=] [.^=] [<<=] [>>=]
~& ~| ~^ - charwise (string) operations
~&= ~|= ~^=
[~&] [~|] [~^] - (hyperversions)
[~&]= [~|]= [~^]=
[~&=] [~|=] [~^=]
?& ?| ?^ - [maybe] C-like bool operations
?&= ?|= ?^= - (result is always just 1 or 0)
[?&] [?|] [?^] - (hyperversions)
[?&]= [?|]= [?^]=
[?&=] [?|=] [?^=]
& | ^ - superpositional operations
&= |= ^= - conjunctive, disjunctive, exclusive
all any one none - conj, disj, excl, dismissive
sum prod cat reduce - [maybe]
[&] [|] [^] - (hyperversions)
[&]= [|]= [^]=
[&=] [|=] [^=]
[all] [any] [one] [none]
[sum] [prod] [cat] [reduce]
~~ !~ - smart match, smart non-match
[~~] [!~] - smart match, smart non-match
like unlike - [maybe]
[like] [unlike] - [maybe]
=> [=>] - pair creator
, [,] - list creator
; [;] - "greater comma", list-of-lists creator
: [:] - adverbial
. [.] - method call
.. [..] - range
... [...] - [maybe] range, exclusive of endpoint
= [=] - assignment
:= [:=] - binding
::= [::=] - binding, but more so
trinary operator:
?? :: - if/else
parens, misc, and quotelike operators
()
[] - [when term is expected]
{} - [when term is expected]
m// - shorthand, "matches"
s/// - shorthand, "substitute"
tr/// - shorthand, "transliterate"
'...' "..." `...` /.../ << >>
q qq qx rx qw [qm?]
[+ qr ?]
<...> - readline
(heredocs) - [exact format unknown]
named unary (prefix) operators, terms, and other important assorteds,
identified
when possible:
-X [-X] - [op] filetest operators
ref [ref] - [op]
exists [exists] - [op]
delete [delete] - [op]
defined [defined] - [op]
undef [undef] - [op]
undef - [term]
temp ? - [op]
let ? - [op]
but ? - [op] val properties
${ } - [deref] dereference scalarref
@{ } - [deref]
%{ } - [deref]
&{ } - [deref]
... - [term] yada**3
Inf - [term]
Nan - [term]
is - [declar] var properties
-> - [declar] like 'sub'
hash - [declar] force hash context
MikeL
Larry Wall
: For this version of the operator list, (since I am unsure that _every_
: _two_) I have placed all of them in EXPLICITLY. Please check that I
: didn't miss any, or put any in that are incorrect.
The problem with cut-and-paste of the regular table is that all the
errors are copied too.
Maybe we should just say that you can put it anywhere that makes sense,
and let the perl parser sort out the sheep from the goats. The basic
rule is that for any op, [op] is also expected in the same place. So
if the user defines a postfix:! for factorial, they automatically get
_[!] for that as well.
I think we could also allow
@a [??] @b [::] @c
But it's not clear whether we can parse
@a = [undef][...]
Larry
Martin D Kealey
> Maybe we should just say that you can put it anywhere that makes sense,
> and let the perl parser sort out the sheep from the goats. The basic
> rule is that for any op, [op] is also expected in the same place.
It would be nice to have a fully generalized set of applicative
manipulators. The basic set in applicative languages like Haskell generally
includes map, zip, fold and do; from these others can be constructed, but
for efficiency in an imperative language we'd probably want a few more like
apply and cross-product.
It strikes me that [op] is a composition of yet more basic facilities; thus
@a [+] @b
would be something like
map { $_[0] + $_[1]) } zip @a, @b
In general it would be nice to be able to make shorthands for arbitrary
compositions; eg, with some definition for "zip" that results in the above,
one could then go simply
@a zip:+ @b
which while not as short as @a [+] @b, is more obviously a specific instance
of a more general construct.
-=*@*=-
Apropos substitution, I still like the idea of having matched sub-strings as
magic L-values. I think the ".=" assignment operator makes this a lot more
feasible than simply using a straight assignment, which as Larry mentioned
before would be problematic with its right-to-left evaluation. But for an
assignment operator that needn't necessarily be the case, and indeed
implicitly is not the case. Using the ".=" operator, we could have:
Perl5: Perl6:
$a =~ s/\d/X/; $a ~ /(\d)/ = "X";
$a =~ s/\d/X/g; $a ~ /(\d)/ [=] "X";
$a =~ s/\d/ ($&+1)%10 /eg; $a ~ /(\d)/ [.=] { ($_+1)%10 };
Or if you don't like switching from = to .=, just stick with ".=" and define
that ".literal" always returns the literal, after evaluating and discarding
the LHS, and ".=literal" likewise evaluates the LHS, then sets the LHS to
the literal value.
> So if the user defines a postfix:! for factorial, they automatically get
> _[!] for that as well.
postfix vs infix ... mumble ... parsing nightmare ... mumble ...
> I think we could also allow
>
> @a [??] @b [::] @c
>
> But it's not clear whether we can parse
>
> @a = [undef][...]
What about
$a = $x lazy:? $y : $z
so that $a is thus an object which when stringified (or numified or
whatever) chooses whether it's $y or $z, but not until?
-Martin
Austin Hastings
--- Larry Wall <la...@wall.org> wrote:
> On Tue, 29 Oct 2002, Michael Lazzaro wrote:
> : For this version of the operator list, (since I am unsure that
> _every_
> : unary/binary op has a meaningful hyper, and some tentatively have
> : _two_) I have placed all of them in EXPLICITLY. Please check that
> I
> : didn't miss any, or put any in that are incorrect.
>
> The problem with cut-and-paste of the regular table is that all the
> errors are copied too.
>
> Maybe we should just say that you can put it anywhere that makes
> sense,
> and let the perl parser sort out the sheep from the goats. The basic
> rule is that for any op, [op] is also expected in the same place. So
> if the user defines a postfix:! for factorial, they automatically get
> _[!] for that as well.
>
What is the correct order of specification for vectorized postfix
operators versus indices?
@subset = @biglist[++][$min .. $max];
@subset = @biglist[$min .. $max][++];
I think the second one suggests (and this should probably be supported,
for the taglinenoise crowd, if no one else) that the postincrement
applies only to the subrange.
=Austin
__________________________________________________
Do you Yahoo!?
HotJobs - Search new jobs daily now
http://hotjobs.yahoo.com/
Austin Hastings
--- Michael Lazzaro <mlaz...@cognitivity.com> wrote:
>
> For this version of the operator list, (since I am unsure that
> _every_
> unary/binary op has a meaningful hyper, and some tentatively have
> _two_) I have placed all of them in EXPLICITLY. Please check that I
> didn't miss any, or put any in that are incorrect.
>
> hyperoperators:
>
> [op] - as prefix to any unary/binary operator, "vectorizes" the
> operator
What, if any, guarantees are there about the order of evaluation for
vectorized operations?
If I say
@b = @a[.meth];
and .meth has a side-effect, what can I expect?
> ?& ?| ?^ - [maybe] C-like bool operations
> ?&= ?|= ?^= - (result is always just 1 or 0)
> [?&] [?|] [?^] - (hyperversions)
> [?&]= [?|]= [?^]=
> [?&=] [?|=] [?^=]
Two possible differences between double-[&|] and single-[&|]:
1- Force (unlazy) evaluation of all operands.
2- Force conversion to 1 or 0. (Are "true" and "false" going to be
built-in literals, a la java?)
Which (or both) of these are supposed to come from the single-op
versions of these?
> & | ^ - superpositional operations
> &= |= ^= - conjunctive, disjunctive, exclusive
What's the precedence for these? Same as C?
If so, what happens when you combine them? Are they associative,
distributive, worse?
Since the flexprs haven't collapsed, what interactions are there when
"appending" to them?
$a = 1 | 5;
$a &= 10;
What's $a?
1 | 5 & 10
(1|5) & 10
(1&10) | (5&10) ?
This is probably my ignorance of this coming through. Maybe I need to
get more presents this Christmas ... :-(
On the other hand, some of the examples seem counterintuitive. That is,
considering Damian's:
$seen = $start | $finish;
for ... -> $line {
print "$line\n" unless $line == $seen;
$seen |= $line;
}
I can understand the notion of "unless $line is a-or-b-or-c-or..." but
I keep THINKING in terms of "I've seen a-and-b-and-c-and..."
So when would multiple flexops be combined? Anyone have any real world
examples, even simple ones?
Buddha Buck
>
> Maybe we should just say that you can put it anywhere that makes sense,
> and let the perl parser sort out the sheep from the goats. The basic
> rule is that for any op, [op] is also expected in the same place. So
> if the user defines a postfix:! for factorial, they automatically get
> _[!] for that as well.
>
> I think we could also allow
>
> @a [??] @b [::] @c
>
> But it's not clear whether we can parse
>
> @a = [undef][...]
How would you parse:
@a = @b[[5]];
(My intent: for @a; @b -> $x is rw; $y { $x = $y[5] }; # I think... )
>
> Larry
>
>
Andrew Wilson
> Larry Wall wrote:
> >I think we could also allow
> >
> > @a [??] @b [::] @c
> >
> >But it's not clear whether we can parse
> >
> > @a = [undef][...]
>
> How would you parse:
>
> @a = @b[[5]];
>
> (My intent: for @a; @b -> $x is rw; $y { $x = $y[5] }; # I think... )
If I wanted to do that, I'd try
@a [=] @b[5];
I have no idea what
@a = @b[[5]];
should do.
andrew
--
Sagittarius: (Nov. 22 - Dec. 21)
It's all over but the shouting, but don't worry: It's going to be
great shouting.
Brent Dax
# How would you parse:
#
# @a = @b[[5]];
A 2D array slice, since you can't hyper numbers?
--Brent Dax <bren...@cpan.org>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
Wire telegraph is a kind of a very, very long cat. You pull his tail in
New York and his head is meowing in Los Angeles. And radio operates
exactly the same way. The only difference is that there is no cat.
--Albert Einstein (explaining radio)
Jonathan Scott Duff
>
> @a = @b[[5]];
>
> (My intent: for @a; @b -> $x is rw; $y { $x = $y[5] }; # I think... )
I'd write that as @a [=] @b[5];
-Scott
--
Jonathan Scott Duff
du...@cbi.tamucc.edu
Austin Hastings
--- Brent Dax <bren...@cpan.org> wrote:
> Buddha Buck:
> # How would you parse:
> #
> # @a = @b[[5]];
>
> A 2D array slice, since you can't hyper numbers?
>
It's hypering the [5].
@a = a list made up of the [5] (sub-)element of each element of @b.
for @b -> @b_subarr { @a.push(@b_subarr[5]); }
Larry Wall
: --- Brent Dax <bren...@cpan.org> wrote:
: > Buddha Buck:
: > # How would you parse:
: > #
: > # @a = @b[[5]];
: >
: > A 2D array slice, since you can't hyper numbers?
: >
:
: It's hypering the [5].
I don't think so. We can't allow general expressions inside a hyper []
where it could be confused with a subscript, if for no other reason than
that people will read it first as a subscript.
In fact, [] for hyper works for postfix and prefix operators only if we
can specifically distinguish the inside operator from an expression.
An earlier message had something like this as a hyper:
@a = @b[.method];
That absolutely won't work, because [.method] is a valid subscript.
In this case it would have to be written
@a = @b[.]method;
But the general problem is just about enough to kill the whole []
idea for hyper. It's really only rescuable if we have a known set of
operators to match against. Then on the basis of the rule of matching
the longest token possible, we can have the hyper interpretation
override any interpretation as a subscript or anonymous array composer.
For example, [undef] is a vector undef only if C<undef> is a member of
that distinguished set of operators.
I think making people remember a distinguished set of operators is a
bad thing, particularly when we've gone to such great lengths to
fuzz the boundary between unary ops, argument method calls, and list
ops that just happen to have one argument at the moment.
So despite the beauty of
@a [+] @b
I think it cannot survive in its current form. It overloads square
brackets too heavily.
Larry
Michael Lazzaro
On Wednesday, October 30, 2002, at 09:25 AM, Larry Wall wrote:
> So despite the beauty of
>
> @a [+] @b
>
> I think it cannot survive in its current form. It overloads square
My own backup proposals would be:
h<+>
h[+]
or similar, e.g. give the brackets a prefix to differentiate them
firmly as 'hyper'. Personally, I still don't mind that extra char,
because it makes it extra-super-obvious; as we've seen (from the 60+
messages posted in the last twelve hours, sheesh), hyper is a concept
that people definitely need "alerting" of. And no sigil, so it doesn't
conflict(?) with anything else.
MikeL
fear...@figaro.weizmann.ac.il
>
> So despite the beauty of
>
> @a [+] @b
>
> I think it cannot survive in its current form. It overloads square
> brackets too heavily.
>
> Larry
>
so may be @a <+> @b
@a < => > @b
@a < , > @b
@a < .= > replace ( /<foo>/ -> { "bar" } )
but
@c = @a < <=> > @b
this work since we do not have unary > or < and parser
will be able to distinguish . also , sinse <...> readline is term , it
does not interfere with <op> . am I right ?
to me <op> is visually more distinctive and less heavy then [op] .
but now it visually interfere with <iterator> and <regexp> .
arcadi .
Jonathan Scott Duff
> But the general problem is just about enough to kill the whole []
> idea for hyper.
Need. More. Punctuation. :-)
> So despite the beauty of
>
> @a [+] @b
>
> I think it cannot survive in its current form. It overloads square
> brackets too heavily.
@a x+ @b
@a `+ @b
@a ^+ @b # I like this one best ;-)
if we did go back to using ^ for hyper I have no clue what to do about
xor. I'd suggest % but I use the modulus too much.
Larry Wall
:
: What, if any, guarantees are there about the order of evaluation for
: vectorized operations?
:
: If I say
:
: @b = @a[.meth];
:
: and .meth has a side-effect, what can I expect?
Well, that's just a subscript, not a hyper. But if it were a hyper, and
if it had side effects, I'd say your program was erroneous, in Ada parlance.
: > ?& ?| ?^ - [maybe] C-like bool operations
: > ?&= ?|= ?^= - (result is always just 1 or 0)
: > [?&] [?|] [?^] - (hyperversions)
: > [?&]= [?|]= [?^]=
: > [?&=] [?|=] [?^=]
:
: Two possible differences between double-[&|] and single-[&|]:
:
: 1- Force (unlazy) evaluation of all operands.
: 2- Force conversion to 1 or 0.
It should do just what the corresponding basic operator would do between
two scalars.
: (Are "true" and "false" going to be built-in literals, a la java?)
Never. Truth is relative in Perl. Having a "true" literal would
imply that objects couldn't decide whether they're true or not, unless
the true literal really means a superposition of all the possible
true values of every type. Which is kinda hard to write, especially
since a type could decide on the fly whether a value is true.
: Which (or both) of these are supposed to come from the single-op
: versions of these?
:
: > & | ^ - superpositional operations
: > &= |= ^= - conjunctive, disjunctive, exclusive
:
: What's the precedence for these? Same as C?
No, the bare ones are tighter than comparisons. All assignment ops are the
precedence of assignment, though.
: If so, what happens when you combine them? Are they associative,
: distributive, worse?
I don't think those terms apply till you collapse.
: Since the flexprs haven't collapsed, what interactions are there when
: "appending" to them?
I dislike the term "flexprs" even though it's kinda cute. I don't
think it communicates what's really going on any better than
"superpositions". Druther call them something ugly like "junctions"
if that communicates better.
Maybe it could be "junks" for short. So you'd read
$a ~~ 1|2|3
as "Does $a match this junk?"
: $a = 1 | 5;
: $a &= 10;
:
: What's $a?
:
: 1 | 5 & 10
: (1|5) & 10
: (1&10) | (5&10) ?
The second, if any. But maybe it should be a no-no to append to a
junk of a different kind. We've already said that appending to a
junk of the same type doesn't add "parentheses". This may be one
of those situations where the assignment operators are overloaded
separately from the basic ops.
: This is probably my ignorance of this coming through. Maybe I need to
: get more presents this Christmas ... :-(
:
: On the other hand, some of the examples seem counterintuitive. That is,
: considering Damian's:
:
: $seen = $start | $finish;
: for ... -> $line {
: print "$line\n" unless $line == $seen;
: $seen |= $line;
: }
:
: I can understand the notion of "unless $line is a-or-b-or-c-or..." but
: I keep THINKING in terms of "I've seen a-and-b-and-c-and..."
:
: So when would multiple flexops be combined? Anyone have any real world
: examples, even simple ones?
I dunno, don't look at me. I'm afraid most of the complicated examples
so far fail the bear-of-very-little-brain test. I would like mere mortals
to be able to understand Perl code in general...
Larry
Larry Wall
: @a x+ @b
: @a `+ @b
: @a ^+ @b # I like this one best ;-)
:
: if we did go back to using ^ for hyper I have no clue what to do about
: xor. I'd suggest % but I use the modulus too much.
Gee, % looks kinda like an X.
Larry
Larry Wall
As well as all the operators containing < or >, which is lots.
I think <> is more problematic than []. At least all the normal
operators don't contain square brackets.
Larry
Larry Wall
: My own backup proposals would be:
:
: h<+>
: h[+]
:
: or similar, e.g. give the brackets a prefix to differentiate them
: firmly as 'hyper'. Personally, I still don't mind that extra char,
: because it makes it extra-super-obvious; as we've seen (from the 60+
: messages posted in the last twelve hours, sheesh), hyper is a concept
: that people definitely need "alerting" of. And no sigil, so it doesn't
: conflict(?) with anything else.
Well, "v" for vector makes a little more sense, maybe. Could be lots of things:
@a *[+] @b
@a .[+] @b
@a =[+] @b
@a ![+] @b
@a ^[+] @b
@a _[+] @b
@a :[+] @b
@a '[+] @b
@a v[+] @b
There's a problem with v[] for postfix ops, though. You'd be required
to use the space-eater after alphanumerics, for instance:
@foo _v[.]method
@foo _v[++]
And the space would also be required! So I don't think "h" or "v" will fly.
Of the others, : seems to work about the best, but maybe that's an illusion
that evaporates when we start using adverbials.
The * has obvious mnemonic value of the splat sort, but also mentally clashes
with the notion of multiplication when using mathematical ops inside.
Larry
fear...@figaro.weizmann.ac.il
>
> Well, "v" for vector makes a little more sense, maybe. Could be lots of things:
>
> @a *[+] @b
> @a .[+] @b
> @a =[+] @b
> @a ![+] @b
> @a ^[+] @b
> @a _[+] @b
> @a :[+] @b
> @a '[+] @b
> @a v[+] @b
>
> There's a problem with v[] for postfix ops, though. You'd be required
> to use the space-eater after alphanumerics, for instance:
>
> @foo _v[.]method
> @foo _v[++]
>
> And the space would also be required! So I don't think "h" or "v" will fly.
> Of the others, : seems to work about the best, but maybe that's an illusion
> that evaporates when we start using adverbials.
>
> The * has obvious mnemonic value of the splat sort, but also mentally clashes
> with the notion of multiplication when using mathematical ops inside.
>
> Larry
>
>
>
v looks like ^ upside down . so maybe
@a ^[ += ] @b
@a^[++]
* we can allow spaces inside [ ]
* ^ does not clash with xor-staff
* and make [ ] around vectorized operator optional where
possible or appropriate .
* this brings us back to more intuitive and not so shouting ^
and xor is ok too .
@a ^[ ^^ ] @b
@a ^[+^]
@a ^[ ^ ] @b
@a ^[ ^^= ] @b
~^ - force to string context, complement
arcadi
Aaron Crane
> @a `+ @b
Ick. In my experience, many people actually don't get the backtick
character at all. They can't find it on the keyboard, and they don't really
see what's so different about it from apostrophe. Indeed, many typefaces
(including common print-media faces, like Courier) make it _really_ hard to
distinguish backtick from apostrophe. I always hate teaching people what
backticks do -- not because the concept is difficult, but because the syntax
is so alien to so many people. So I teach qx// for Perl, and $() for Unix
shell, and I throw in backticks as an extra 'you might also see this'
affair.
Anyway, that was a bit of a rant, but what I mean is: I'd actually be
in favour of avoiding backtick entirely in operators.
--
Aaron Crane * GBdirect Ltd.
http://training.gbdirect.co.uk/courses/perl/
Aaron Crane
> @a ^[+] @b
I like this one in preference to plain ^+, but (unless I'm missing
something) it still leaves the question of what to do with xor.
> @a '[+] @b
Doesn't this reinvent the $Package'symbol problem?
> The * has obvious mnemonic value of the splat sort, but also mentally clashes
> with the notion of multiplication when using mathematical ops inside.
Hmm.
@a *[+] @b
@a *[*] @b
@a *[**] @b
I think I could cope, if only because the brackets highlight the vectorised
operator more than the outside symbol.
How about tilde?
@a ~[+] @b
If I'm successfully playing along at home, I think that means the match
operator has to be ~~ or =~, but I can live happily with either of those.
--
Aaron Crane * GBdirect Ltd.
Me
>
> @a [+] @b
>
> I think it cannot survive in its current form. It overloads square
> brackets too heavily.
What about using colon thus:
@a [:+] @b
or other character after the opening bracket, so long as that
character is not valid as the initial character of a prefix op or
term.
There's also:
@a []+ @b
--
ralph
Dave Storrs
for @a; @b -> $x is rw; $y { $x = $y[5] };
And I finally had to whimper publicly about this.
I've been lurking around the P6 process since the very beginning of the
RFC process. I saw the new 'for' syntax come out, and I've watched it get
used by lots of people on this list. My first reaction to it was "that's
counterintuitive and scary, and I don't like it". But, that was my
reaction to a lot of the new Perl syntax, and I found that if I just sat
back and pondered it for a bit, I would soon come to realize that the new
syntax was fine, just different--and usually an improvement.
I have honestly tried to have the same sort of reconciliaton with the new
'for' syntax, and I just can't. It's possible that I still just don't
understand it (I'm not sure I do), but I really believe that this syntax
is a Bad Thing and is going to cause a lot of bugs. I have the following
problems with it:
for @a; @b -> $x is rw; $y { $x = $y[5] };
1) This is (AFAIK) the ONLY place in Perl where a semicolon that
is not enclosed in parens is used for anything other than "end of
statement" (semi is used to separate parts of a perl5 C-style for loop
control statement, but that's in parens, so there is an indication that
the statement isn't over yet).
2) The fact that the $x and $y variables are, by default,
read-only is (again, IMO) bad. Perl's design philosophy has always been
"by default, all the freedom (and risk) that's available; if you want less
let me know". Therefore, by default, these variables should be rw, and
you should be able to ask to have them const.
3) Following that same idea, "is rw" is poor Huffman encoding
for something I'm likely to want fairly often. Could we at least come up
with a single character equivalent? Perhaps something like this:
@a -> $x< # rw ("$x can be an lvalue")
@a -> $x> # r ("$x can be only be an rvalue")
Either of these could be the default. Of course, what I'd really
like to see is:
@a -> $x # rw (default)
@a -> $x< # rw (explicitly stated)
@a -> $x> # r ("$x can only be an rvalue")
I believe the parser should be able to separate '<' used to mean
"can be an lval" from '<' used to mean "less than"...after all, you would
never alias elements in an array to a _value_ (which is what is returned
by $x < $y)...you would only alias elements to a variable. If I'm wrong,
please correct me. If it's going to be a problem, we could clarify it by
putting the bracket to the left of the variable, but then there is some
visual confusion with the head of the arrow operator.
3) While it's really convenient to be able to loop over multiple
arrays and have each one alias to a separate variable, right now the
connection between the array and its alias variable is tenuous at
best...you don't know that $b is aliased until you read down the entire
statement (passing over a semicolon in the way that makes it look like
things have ended). We explicitly moved regex modifiers to the front to
make them more visually distinct and easier to parse; shouldn't we
consider something similar here?
4) Finally, and related to #3, the current syntax makes it look as
though $x is being pulled out of @b, when in fact it is being pulled out
of @a.
I'm not a language designer and, usually, when I try to suggest
things I end up not seeing problems that they will cause with parsing.
However, just so this post does not consist entirely of negativism, I will
try to come up with a workable alternate syntax:
Current: for @a; @b -> $x is rw, $y; $z { ...stuff... };
The above (IIUC) means "loop over @a, pulling out two elements at a time
and aliasing them to $x (which is rw) and $y (which is r).
Simultaneously loop over @b, aliasing its elements to $z (which is r)."
Suggested: for @a -> $x, $y> __ @b -> $z> { ...stuff... };
The above means the same thing, but instead of specifying that $x is rw,
we have specified that $y and $z are r.
At the bottom of this email are a bunch of other options, but the
one above is the one that I like best. My reasons are as follows:
1) Larry seems to have put a strong premium on not needing parens,
so I set that as an absolute requirement.
2) Although having all the streams on the left is very convenient,
I judged it more important to be clear about which stremas were
aliasing to which variable(s).
3) The new operator that I am proposing ("__") serves two
purposes: for the human, it introduces a visual break which draws the eye
and makes you notice that there is another stream there, and for the
machine it says "ok, we're done with the list of variables being aliased
from @a...here's the next stream". I propose calling it the "bridge"
operator, because you use it to cross one stream in order to get to the
next. I deliberately made it a digraph, because (1) it provides a better
visual break that way and (2) it leaves the single character '_' operator
available for some less specialized purpose. (Although, if anyone
wants to suggest a more generalized use for it, I'd love to see
it.) Because underscore is a legal character in an identifier, there will
need to be whitespace between the bridge and the variable immediately
before it. I tried some alternatives, but didn't like any of them as
well.
Here are the other suggestions I can up with:
for @a -> $x<; @b -> $y { $x = $y[5] };
for @a : $x< __ @b : $y { $x = $y[5] };
for @a ~> $x< __ @b ~> $y { $x = $y[5] };
for @a )~ $x<, $z __ @b )~ $y { $x = $y[5] };
for @a _ @b __ $x<, $z _ $y { $x = $y[5] };
for @a _ @b )~ $x<, $z _ $y { $x = $y[5] };
for @a _ @b ]~ <$x, $z _ $y { $x = $y[5] };
There were actually a bunch of others, but they were even less
satisfying.
What do you all think? Any value here?
--Dks
Michael Lazzaro
On Wednesday, October 30, 2002, at 12:48 PM, Dave Storrs wrote:
> for @a; @b -> $x is rw; $y { $x = $y[5] };
I agree that it's an eyeful. How many of your issues could be solved
if the above were just written:
for (@a;@b) -> ($x is rw; $y) { $x = $y[5] };
Would that suffice to make it clearer?
MikeL
Jonathan Scott Duff
> Current: for @a; @b -> $x is rw, $y; $z { ...stuff... };
>
> The above (IIUC) means "loop over @a, pulling out two elements at a time
> and aliasing them to $x (which is rw) and $y (which is r).
> Simultaneously loop over @b, aliasing its elements to $z (which is r)."
>
> Suggested: for @a -> $x, $y> __ @b -> $z> { ...stuff... };
Just as a data point, I find yours harder to read.
Austin Hastings
--- Dave Storrs <dst...@dstorrs.com> wrote:
> for @a -> $x<; @b -> $y { $x = $y[5] };
Yes!!!
(Except for the '<'. That's feigen-ugly. I'll say "is r?" where needed,
regardless of which is the default. I prefer default=ro, though,
because that let's the optimizer do more by default.)
I proposed the multiple arrow thing a long while back, but it didn't
work out because of precedence with comma and because of
topicalizing/binding/etc.
But that was before semicolon which can have a different precedence
from arrow. And screw the binding -- it just looks right:
for @first -> $a;
@pairs -> $b is rw, $c;
{
print "woo-hoo!\n";
}
In fact, the semicolons even make it look like local variable
declarations from K&R 'C', so my frog-brain doesn't twitch.
> What do you all think? Any value here?
Beaucoup.
=Austin
__________________________________________________
Yahoo! - We Remember
9-11: A tribute to the more than 3,000 lives lost
http://dir.remember.yahoo.com/tribute
fear...@figaro.weizmann.ac.il
in principle , as I understand , initially the choice of single -> in
the "for" loop was because that makes it cute substitute for "sub"
and makes "for" loop (almost) a function .
But for is not a function it makes some grammar magic before "real"
work. e.g , different meaning of ";" inside closure signature .
so why not to allow it to make also special meaning of -> ? So that it
is not "exactly" sub declaration but sort of ; and then "immediate
component" ("macro" - from one of couple-of-days-ago posts of Larry Wall )
of for loop will cut and paste to reconstruct incoming
stream list and closure signature .
for @a -> $x is rw;
@b -> $y
{ $x = $y[5] };
";" between "for" and { ... } cannot be misinterpreted because parser
know it have to get to { ... } . That means for loop without block is
illegal .
and the () can be placed wherever one please here , they just mean
grouping .
aracadi
fear...@figaro.weizmann.ac.il
> is a Bad Thing and is going to cause a lot of bugs. I have the following
> problems with it:
>
> for @a; @b -> $x is rw; $y { $x = $y[5] };
>
> 1) This is (AFAIK) the ONLY place in Perl where a semicolon that
> is not enclosed in parens is used for anything other than "end of
> statement" (semi is used to separate parts of a perl5 C-style for loop
> control statement, but that's in parens, so there is an indication that
> the statement isn't over yet).
>
in principle , first ";" can be "labelled" as stream separator since
parser know that for is expecting { closure } ;
the second ";" - is distinguished from ";" statement separator ,
since we know that we are inside sub signature and there have to be a
block . That's how I understand it.
> for @a ~> $x< __ @b ~> $y { $x = $y[5] };
> for @a )~ $x<, $z __ @b )~ $y { $x = $y[5] };
> for @a _ @b __ $x<, $z _ $y { $x = $y[5] };
> for @a _ @b )~ $x<, $z _ $y { $x = $y[5] };
> for @a _ @b ]~ <$x, $z _ $y { $x = $y[5] };
>
> There were actually a bunch of others, but they were even less
> satisfying.
for @a -> $x is rw ;
@b -> $y
{ ... } ;
for @a ; @b ->
$x is rw ; $y
{ ... }
arcadi .
Richard Proctor
> An earlier message had something like this as a hyper:
>
> @a = @b[.method];
>
> That absolutely won't work, because [.method] is a valid subscript.
> In this case it would have to be written
>
> @a = @b[.]method;
>
> But the general problem is just about enough to kill the whole []
> idea for hyper. It's really only rescuable if we have a known set of
> operators to match against. Then on the basis of the rule of matching
> the longest token possible, we can have the hyper interpretation
> override any interpretation as a subscript or anonymous array composer.
>
> For example, [undef] is a vector undef only if C<undef> is a member of
> that distinguished set of operators.
The [] made it look appropriate, if the problem is ambiguity then
perhaps the contents of the [] need a prefix to force hyper interpretation
if it could be ambiguous. These are special, powerful cases and the clearer
they are made the better - minimal huffman coding is not necessary.
[+] - hyper meaning is clear
[.method] - fix meaning as the subscript
[*.method] - for some "*" forces hyper context, all it requires is another
60 mesages to undecide on what "*" should be.
Richard
--
Personal Ric...@waveney.org http://www.waveney.org
Telecoms Ric...@WaveneyConsulting.com http://www.WaveneyConsulting.com
Web services Ric...@wavwebs.com http://www.wavwebs.com
Independent Telecomms Specialist, ATM expert, Web Analyst & Services
Damian Conway
>>> for @a; @b -> $x is rw; $y { $x = $y[5] };
>>
>>I agree that it's an eyeful. How many of your issues could be solved
>>if the above were just written:
>>
>> for (@a;@b) -> ($x is rw; $y) { $x = $y[5] };
>>
>>Would that suffice to make it clearer?
>
>
> Actually, yes, that would solve everything for me...and I knew
> this was valid syntax.
So is this vertical layout, which I think will become fairly standard
amongst those who care about readability:
for @a ; @b
-> $x is rw ; $y { $x = $y[5] };
Damian
Dave Storrs
On Wed, 30 Oct 2002, Michael Lazzaro wrote:
Actually, yes, that would solve everything for me...and I knew
this was valid syntax. However, (A) the fact that Larry went to some
fairly serious lengths to eliminate the need for parens everywhere he
could says to me that we should find a system that doesn't require them
and (B) since it CAN be written in the 'eyeful' way (*) it WILL be written
in that way...and I and others are going to have to maintain code that
uses that and, as I said, I think it's going to lead to a lot of bugs.
Maybe I'm the only one who is bothered by this...if so, I'll cope and
deal.
--Dks