[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
Damian Conway
> : 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.
Just put that alpha down and back away quietly, mister.
There's no need for anyone to get hurt here.
;-)
Damian
Dave Storrs
On Thu, 31 Oct 2002, Damian Conway wrote:
> Dave Storrs wrote:
>
> > 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] };
To be honest, this just makes it less readable for me.
--Dks
Larry Wall
I think decent formatting would make it clearer:
for @a ; @b
-> $x is rw; $y {
$x = $y[5];
}
But just a single line break helps a lot:
for @a; @b
-> $x is rw; $y { $x = $y[5] };
But adding parens into a signature might actually make it incorrect,
depending on whether we go with [] or () for subsignatures. And putting
parens around (@a;@b) is likely to produce [@a],[@b], which would
bind to the signature wrong regardless of how it was written.
Larry
Dave Storrs
On Wed, 30 Oct 2002, Austin Hastings wrote:
>
> --- Dave Storrs <dst...@dstorrs.com> wrote:
>
> > for @a -> $x<; @b -> $y { $x = $y[5] };
>
> Yes!!!
>
> (Except for the '<'. That's feigen-ugly.
*shrug* You may not like the aesthetics, but my point still
stands: "is rw" is too long for something we're going to do fairly often.
Give me any one- or two- character marker you want that means "rw" (if
"ro" is the default) or "r" (if "rw" is the default).
> I prefer default=ro, though,
> because that let's the optimizer do more by default.)
I don't feel strongly enough about this to argue it. Personally,
I prioritize readablility over ease-of-optimization...I let Moore's law
take care of speed. Other people, who work in other problem domains than
I do, may need to have other priorities.
> 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";
> }
You're right, that does look good...but you had to manually insert
whitespace in to make it look good. And (assuming that you used a TAB to
indent the '@pairs...' line), assuming that my TAB settings are the same
as yours.
The problem is, if we make those assumptions, I can even make the
current syntax look (reasonably) good:
for @a; @b
-> $x is rw; $y
{
....
}
--Dks
Angel Faus
Then let's make the parens required when there is more than one
stream.
Sane people will put them there anyway, and it will force the rest of
us to behave.
It also solves the ";"-not-a-line-seperator problem.
-angel
Dave Storrs
On Wed, 30 Oct 2002, Angel Faus wrote:
> Then let's make the parens required when there is more than one
> stream.
>
> Sane people will put them there anyway, and it will force the rest of
> us to behave.
>
> It also solves the ";"-not-a-line-seperator problem.
>
> -angel
Yes! Thank you, this is perfect. Minimal disruption of the
syntax Larry designed, minimal exception to remember, and it completely
resolves all my issues. See, I knew there had to be a simple, elegant
solution I was missing.
--Dks
fear...@figaro.weizmann.ac.il
but this will make
for ( @a ; @b ) -> ( $x ; $y ) { ... }
to do not what you mean :
Because it is this :
for [@a] , [@b] -> $x ; $y { ... $x,$y are array refs here }
";" is dangerous because it impose scalar context on both sides.
by enclosing ( @a;@b) in () you "hide" @a;@b from grammar magic that
"for" is doing , so "for" do not know how to bind the streams to
closure args.
aracdi
Graham Barr
> *shrug* You may not like the aesthetics, but my point still
> stands: "is rw" is too long for something we're going to do fairly often.
I am not so sure. If I look back through a lot of my code, there are more cases
where I use the variable in a read-only fashion than I do for modifying
the value.
Graham.
Simon Cozens
> minimal exception to remember
Another one for my irregularity check, thanks! :)
--
"Though spring is here, to me it's still September,
That September, in the rain"
- Dinah Washington, The USENET Anthem.
Dave Storrs
Ok, fair enough.
--Dks
Damian Conway
>> ?& ?| ?^ - [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?
Superpositions don't lazily evaluate their operands (unless those
operands are themselves superpositions).
And they certainly don't convert to binary.
> Since the flexprs haven't collapsed, what interactions are there when
> "appending" to them?
>
> $a = 1 | 5;
> $a &= 10;
C<&> is higher precedence that C<|> so...
> What's $a?
>
> 1 | 5 & 10
Yes (by precedence)
> (1|5) & 10
Yes (explcitly).
> (1&10) | (5&10) ?
Yes (by the rules of boolean algebra)
> 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..."
That's understandable. So you write:
$seen = $start & $finish;
for ... -> $line {
print "$line\n" if $line != $seen;
$seen &= $line;
}
> So when would multiple flexops be combined? Anyone have any real world
> examples, even simple ones?
Sure (for sufficiently complex values of simple ;-)
Here's how to find the love of your life:
$requirements = "tall" & "dark & "handsome"
| "old" & "rich"
| "Australian";
for <> -> $candidate {
my $traits = any( split /<ws>/, $candidate );
print "True love: $candidate\n"
if $requirements eq $traits;
}
Of course, not everyone can hope to be lucky enough to meet an Australian,
but you get the idea. ;-)
Damian
Brent Dax
# Here's how to find the love of your life:
#
# $requirements = "tall" & "dark & "handsome"
# | "old" & "rich"
# | "Australian";
#
# for <> -> $candidate {
# my $traits = any( split /<ws>/, $candidate );
# print "True love: $candidate\n"
# if $requirements eq $traits;
# }
So, the love of my life is:
Function call found where operator expected at - line 1, near
""dark & "handsome"
That figures, actually, considering my social life...
--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)
Damian Conway
> So, the love of my life is:
>
> Function call found where operator expected at - line 1, near
> ""dark & "handsome"
>
> That figures, actually, considering my social life...
Thanks. Would the hypothetical example collector please archive the
corrected version instead:
$requirements = "tall" & "dark" & "handsome"
| "old" & "rich"
| "Australian";
for <> -> $candidate {
my $traits = any( split /<ws>/, $candidate );
print "True love: $candidate\n"
if $requirements eq $traits;
}
Damian
Damian Conway
> 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.
Yes. Rather than C<true> and C<false> constants, we may
have C<true> and C<false> predicates (that correctly handle the
nuances of Perl 6 booleans). We will certainly have
unary prefix operators for determining truth/falsehood
(i.e. C<?> and C<!>).
> : If so, what happens when you combine them? Are they associative,
> : distributive, worse?
>
> I don't think those terms apply till you collapse.
Yep. The superpositional operators effectively build a value that's
like a parse tree of the original operand values.
> 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.
I certainly don't mind "junctions".
Takes me back to my electrical engineering days! ;-)
I'll call them "junctions" from now on.
> Maybe it could be "junks" for short. So you'd read
>
> $a ~~ 1|2|3
>
> as "Does $a match this junk?"
Err. Yeah. Great.
;-)
> : 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.
I think not. It's important to be able to compose "higher-order"
superpositions. And to be able to do so via the assignment variant.
> 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.
I don't believe that's necessary or appropriate. I think it's
important to be able to "append" consistently, regardless of the
current value of the LHS.
Damian
Smy...@stripey.com
> Jonathan Scott Duff writes:
>
> > @a `+ @b
>
> In my experience, many people actually don't get the backtick
> character at all.
Yes. I think that might be a good reason _for_ using backtick in vector
operators:
* Backticks aren't used in any other operators, so they would not be
mistaken for xor nor arrays.
Backticks also look a little odd, so even if it isn't intuitive as
to what is going on, somebody seeing a vector op for the first time
should at least spot that _something_ different is happening.
* People starting out in Perl wouldn't want to use vector ops straight
away (there are enough other things to be learning). So a character
that involves 'advanced' typing is used for an 'advanced' feature.
A pair of backticks could be used if the vector-equals distinction is
required:
@a `+`= @b;
@a `+=` @b;
> 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.
I don't think backticks for vector conflicts with backticks for
invoking a shell (cos the latter is a term not an op), I'd be in favour
of removing the current backtick behaviour anyway:
* It looks like quoting, and it isn't really. It's more like a
function call.
* Many people use backticks when C<system()> is desired. The fact
that these two similar features look so different from each other us
confusing.
Also, if backticks were to be used for vector ops then removing the
existing use would mean that backticks are _only_ for vector ops. No
'small exceptions' -- the very simple rule that backticks are always
vector ops.
> 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.
I can see where you're coming from there. They are an awkward glyph.
But Larry's short enough of characters as it is: I don't think we can
afford to throw one away entirely, however unpleasant it is.
Smylers
Graham Barr
> Yesterday Aaron Crane wrote:
>
> > Jonathan Scott Duff writes:
> >
> > > @a `+ @b
> >
> > In my experience, many people actually don't get the backtick
> > character at all.
>
> Yes. I think that might be a good reason _for_ using backtick in vector
> operators:
> A pair of backticks could be used if the vector-equals distinction is
> required:
>
> @a `+`= @b;
> @a `+=` @b;
Thats ugly, IMO.
Now this is going to sound wild (probably) and I have not thought too much
about it and there are probably others who can see the pitfalls quicker
then me. But could () be available for hyper operators ?
I will sit back now and watch the firewaorks, as I wont be in the UK
on Nov 5 :-)
Graham.
Austin Hastings
--- Damian Conway <dam...@conway.org> wrote:
> Austin Hastings wrote:
>
> >> ?& ?| ?^ - [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?
>
> Superpositions don't lazily evaluate their operands (unless those
> operands are themselves superpositions).
Sorry, let me be more explicit: Forget the flexops for now. What's a
C-like boolean single-letter do?
> >> - [maybe] C-like bool operations
> >> - (result is always just 1 or 0)
In the C that I learned, the &^| ops were bitwise.
Likewise, the && || ops were lazy booleans.
So what's a single-letter boolean act like? Is it lazy? Does it retain
its bitwise-ness but (since boolean) force evaluation for 1 or 0 first?
I just don't understand what the "implied" behavior is, since the
reference is outside my experience.
> > $a = 1 | 5;
> > $a &= 10;
> > What's $a?
> >
> > 1 | 5 & 10
>
> Yes (by precedence)
Umm, is this wrong? As I understand it, that's the same as 1 | (5&10)
because of precedence, no?
> > (1|5) & 10
>
> Yes (explcitly).
(With apologies to the folks at "Sesame Street"):
One of these answers isn't like the other ...
One of these answers just doesn't belong ...
> > 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..."
>
> That's understandable. So you write:
>
> $seen = $start & $finish;
> for ... -> $line {
> print "$line\n" if $line != $seen;
> $seen &= $line;
> }
Yeah, that's better. Thanks.
> > So when would multiple flexops be combined? Anyone have any real
> world
> > examples, even simple ones?
>
> Sure (for sufficiently complex values of simple ;-)
>
> Here's how to find the love of your life:
>
> $requirements = "tall" & "dark & "handsome"
> | "old" & "rich"
> | "Australian";
>
> for <> -> $candidate {
> my $traits = any( split /<ws>/, $candidate );
> print "True love: $candidate\n"
> if $requirements eq $traits;
> }
>
> Of course, not everyone can hope to be lucky enough to meet an
> Australian, but you get the idea. ;-)
Well, thank God for small favors.
traits = any ( ... )
requirements = .. & ..
if $requirements eq $traits
Should that be traits = all()?
I mean, assuming that the split returns only adjectives, you've got
something like:
"short" & "busty" & "dark" & "nymphomaniac" & "father owns a chain of
liquor stores"
in the requirements
and you've got
a | b | ... | z
in the traits
How do THOSE work together?
(In other words: Can you write Apoc.Flexible now, please?)
=Austin
__________________________________________________
Do you Yahoo!?
HotJobs - Search new jobs daily now
http://hotjobs.yahoo.com/
Austin Hastings
--- Smy...@stripey.com wrote:
> Yesterday Aaron Crane wrote:
>
> > Jonathan Scott Duff writes:
> >
> > > @a `+ @b
> >
> > In my experience, many people actually don't get the backtick
> > character at all.
>
> Yes. I think that might be a good reason _for_ using backtick in
> vector
> operators:
>
> * Backticks aren't used in any other operators, so they would not
> be
> mistaken for xor nor arrays.
>
> Backticks also look a little odd, so even if it isn't intuitive
> as
> to what is going on, somebody seeing a vector op for the first
> time
> should at least spot that _something_ different is happening.
>
> * People starting out in Perl wouldn't want to use vector ops
> straight
> away (there are enough other things to be learning). So a
> character
> that involves 'advanced' typing is used for an 'advanced'
> feature.
This almost makes more sense than the ^[] stuff. But see below.
> A pair of backticks could be used if the vector-equals distinction is
> required:
>
> @a `+`= @b;
> @a `+=` @b;
Now it does make more sense. Use them as quotes, please, since that's
the understood usage (and becase syntax highlighters know how to do
this).
I don't even mind if they keep the "dual use" of run-gather and
vectorize. (They probably can't, since prefix ops would look like
run-gathers.)
@a = @b `+` @c;
"let @a be the result of running PLUS with inputs @b and @c"
Yeah!
Larry Wall
: On Thu, Oct 31, 2002 at 12:16:34PM +0000, Smy...@stripey.com wrote:
: > A pair of backticks could be used if the vector-equals distinction is
: > required:
: >
: > @a `+`= @b;
: > @a `+=` @b;
:
: Thats ugly, IMO.
:
: Now this is going to sound wild (probably) and I have not thought too much
: about it and there are probably others who can see the pitfalls quicker
: then me. But could () be available for hyper operators ?
It would work for binary ops, but unfortunately, nothing that looks
like a term can work for unary ops. (Also parens are already used
as a postfix operator that means call the preceding function ref.)
Larry
fear...@figaro.weizmann.ac.il
>
> Now this is going to sound wild (probably) and I have not thought too much
> about it and there are probably others who can see the pitfalls quicker
> then me. But could () be available for hyper operators ?
>
> I will sit back now and watch the firewaorks, as I wont be in the UK
> on Nov 5 :-)
>
> Graham.
>
>
>
yes if you demand a prefix
@a ^(+=) @b
where ^ can be replaced (almost ) everything .
arcadi .
Ed Peschko
> I think decent formatting would make it clearer:
>
> for @a; @b
> -> $x is rw; y {
> $x = $y[5];
> }
But this isn't very scalable:
for @a; @b;
@c; @d;
@e
-> $a_variable1 is rw, $a_variable2 is rw; $b_variable is rw;
$c_variable is rw; $d_variable is rw;
$e_variable1 is rw, $e_variable2 is rw
{
}
wheras:
for @a -> $a_variable1 is rw, $a_variable2 is rw;
@b -> $b_variable is rw;
@c -> $c_variable is rw;
@d -> $d_variable is rw;
@e -> $e_variable1 is rw, $e_variable2 is rw;
{
}
is much, *much* clearer. IMO the current 'for' syntax suffers from action at a
distance, even if that distance is within the same line. Related things aren't
paired up nearly close enough to each other.
And I'd curse it if I was writing 'for' expressions as complicated as the
second one. Which I WILL do, especially when writing code generators.
Ed
Damian Conway
> In the C that I learned, the &^| ops were bitwise.
>
> Likewise, the && || ops were lazy booleans.
>
> So what's a single-letter boolean act like? Is it lazy? Does it retain
> its bitwise-ness but (since boolean) force evaluation for 1 or 0 first?
> I just don't understand what the "implied" behavior is, since the
> reference is outside my experience.
Since they're producing a boolean result, both C<?&> and C<?|> could be
implemented lazily. However, I suspect they mightn't be, just to keep
them consistent (in their evaluation of operands) with the other bitwise
ops.
>
>>>What's $a?
>>>
>>>1 | 5 & 10
>>
>>Yes (by precedence)
>
>
> Umm, is this wrong?
Yep. Sorry.
>>>(1|5) & 10
>>
>>Yes (explcitly).
This one is still correct.
> traits = any ( ... )
> requirements = .. & ..
> if $requirements eq $traits
>
> Should that be traits = all()?
No. Because later we say (effectively):
print "True love\n"
if all(@desiderata) eq any(@traits)
In other words we want *all* the desired characteristics to be matched
by *some* trait. If the comparison was C<all(...) eq all(...)>, then
you're asking for every characteristic to be the same as every trait,
which obviously can't happen.
This is just a case where the "logic" of English phraseology has
several implicit assumptions that computational logic can't just
fudge over.
> (In other words: Can you write Apoc.Flexible now, please?)
Well, I'd *like* to, but since that would involve giving up my first
vacation in two years, and consequently getting divorced...no.
;-)
Damian
Damian Conway
> Larry Wall writes:
>
>
>>I think decent formatting would make it clearer:
>>
>>for @a; @b
>> -> $x is rw; y {
>> $x = $y[5];
>>}
>
>
> But this isn't very scalable:
Sure it is. You just have to think more two-dimensionally...
for @a; @b; @c; @d; @e
-> $a_variable1 is rw, $a_variable2 is rw;
$b_variable is rw;
$c_variable is rw;
$d_variable is rw;
$e_variable1 is rw, $e_variable2 is rw
{
}
:-)
BTW, Both Larry and I do understand the appeal of interleaving
sources and iterators. We did consider it at some length back
in January, when we spent a week thrashing this syntax out.
Of course, I can't speak for Larry, but in the end I concluded
that interleaving iterator variables is a false win, since it
trades reduced syntactic complexity for increased semantic
complexity, but only really improves the readability of a
comparatively rare case.
Damian
Smylers
> On Thu, Oct 31, 2002 at 12:16:34PM +0000, Smy...@stripey.com wrote:
>
> > ... using backtick in vector operators ... A pair of backticks could
> > be used if the vector-equals distinction is required:
> >
> > @a `+`= @b;
> > @a `+=` @b;
>
> Thats ugly, IMO.
Oh, I wasn't claiming that it's pretty. I think we're past being able
to find something that's pretty.
In general I find backticks fairly jarring on the eyes, but they have to
be used for _something_ ...
Smylers
fear...@figaro.weizmann.ac.il
>
> BTW, Both Larry and I do understand the appeal of interleaving
> sources and iterators. We did consider it at some length back
> in January, when we spent a week thrashing this syntax out.
>
> Of course, I can't speak for Larry, but in the end I concluded
> that interleaving iterator variables is a false win, since it
> trades reduced syntactic complexity for increased semantic
> complexity, but only really improves the readability of a
> comparatively rare case.
>
> Damian
>
but why ? I am just curious about details.
is it complicated for "immediate component" of for loop ( mentioned by
Larry Wall ) to cut-and-paste to reconstruct the original stream list
and block signature.
1) for @a -> $x ; @b -> $y { ... }
===>>>
2) for @a ; @b -> $x ; $y { ... }
at the price of -> not being consistently closure declarator
*everywhere* and having a bit different meaning inside for ( and only
for , because all other topicalizers dont know about streams -- am I
right ?) . Which it is already not exactly , since immediate component
of for loop preprocess the closure signature to match the streams .
and besides, it seems to me that both 1) and 2) can coexist since for
loop can controll what happens between "for" and {...} . but maybe I
am wrong.
I am just curious .
arcadi .
Simon Cozens
> 1) for @a -> $x ; @b -> $y { ... }
>
> ===>>>
>
> 2) for @a ; @b -> $x ; $y { ... }
You've got it! Semicolon naturally breaks things apart, not groups them
together!
--
Anything to do with HTML processing /usually/ involves a pact
with an evil supernatural being, I find.
-- Sean Burke
Austin Hastings
> > requirements = .. & ..
> > if $requirements eq $traits
> >
> > Should that be traits = all()?
>
> No. Because later we say (effectively):
>
> print "True love\n"
> if all(@desiderata) eq any(@traits)
>
> In other words we want *all* the desired characteristics to be
> matched
> by *some* trait. If the comparison was C<all(...) eq all(...)>, then
> you're asking for every characteristic to be the same as every trait,
> which obviously can't happen.
>
> This is just a case where the "logic" of English phraseology has
> several implicit assumptions that computational logic can't just
> fudge over.
Does this imply some sort of "depth matching" is required for these
expressions?
In this case, there's
T = tall & dark & handsome
D = (tall & dark & handsome) | (Australian) | (rich & old)
So when I say:
all(@desiderata) # I hated that ^[!]() poem
does that implicitly "search down" until it finds a singleton
(Australian) or a conjunction (old & rich)?
And likewise does saying
any(@traits)
do some sort of implicit (de) construction looking for a singleton or a
disjunction?
Obviously, yes.
So you're saying that the all() can't work at the a|b|c level, because
that would be conjunctive disjunction. (Doc, tell me straight: how
long do I have?) So the evaluation alternates through the
possibilities, looking for a chance to apply "all".
But on the other side, not all of the traits have to be "matched." It
won't be fatal if the traits are
tall & dark & handsome & socialist
old & rich & fat
Australian & impotent
so long as some subset (ANY?) of the traits completely match ALL the
desired bits.
So I can't use "all(@traits)" because that would OVERSPECIFY.
But I don't feel right using "any(@traits)" because that feels like
either saying
"traits[x] == all-these-things"
which is wrong, or
"traits was a list, like desiderata, which contains one of these"
which is wrong, too. It's right to say
"there is SOME trait in @traits that matches each @desiderata"
But of course, SOME is "choose one", and that means "any".
(BTW: Will there be an alternate build of p6 that does NOT depend on
the axiom of choice?)
Damian, your reward for this whole flexible values mess is to spend the
rest of your life being retained by large companies to explain this
stuff to blockheads like me. Welcome to hell.
Luke Palmer
> Date: Thu, 31 Oct 2002 14:07:34 -0800 (PST)
> From: Austin Hastings <austin_...@yahoo.com>
> Reply-To: Austin_...@yahoo.com
> X-SMTPD: qpsmtpd/0.12, http://develooper.com/code/qpsmtpd/
I think you've got it mixed up: all() and any() don't work with junk,
they _are_ junk.
any($a) is just $a
all($a) is just $a
It doesn't do matching, not unless it collapses right there. So the
only time it does matching is when it collapses, which has nothing to
do with whether all() or any() are present. It has to do with whether
a value is a junction.
all(1, 2, 3) === 1 & 2 & 3
any(1 & 2 & 3) is still just 1 & 2 & 3
It matches:
all(1, 2, 3) < $x
1 & 2 & 3 < $x
because the junction is forced to collapse there. Understand?
Luke
Iain 'Spoon' Truskett
[...]
> for @a -> $a_variable1 is rw, $a_variable2 is rw;
> @b -> $b_variable is rw;
> @c -> $c_variable is rw;
> @d -> $d_variable is rw;
> @e -> $e_variable1 is rw, $e_variable2 is rw;
> {
> }
> is much, *much* clearer. IMO the current 'for' syntax suffers from
> action at a distance, even if that distance is within the same line.
> Related things aren't paired up nearly close enough to each other.
Give this man a +1. I do prefer to have associated things placed
with each other. And, as Simon pointed out, ';' is used to break
things apart, thus the syntax above makes somewhat more sense.
The best part is that I can easily comment out, delete, add part of
the expression without worrying that I'm deleting the wrong thing.
It may not be often that I will use the construct for multiple
iterators, but I can foreseeably use at least 2, and with the
added ease I can imagine using more =)
cheers,
--
Iain.
Austin Hastings
Maybe I just think differently. When I'm trying to actually DO the
comparison, I'm forcing at least a partial collapse, no?
I mean, maybe the traits are
tall & dark & old & handsome & Australian
so the three choices collapse to two, either of which would match.
But regardless, when the actual == appears in the code, some
determination needs to be made in order to figure out which way to go.
So I'm trying to build rules in my brain for how these things are
"compatible-ized?"
And I'm trying to figure out when to specify which junction.
Luke Palmer
that does it:
sub bar();
sub postfix:bar($x) returns IO::Handle;
$x = length <bar>;
If it's possible to have a distinct sub and an operator with the same
name. If not, I believe the distinction is precisely the same as that
of named unary op with its argument optional. Except with infinite
lookahead. Ummm, okay, it's not possible. Because of less than and
friends, it's less possible than [op].
Luke
Luke Palmer
sub hyperless ($left, $right) {
given {.isa Disjunction} {
when $left {
? grep { hyperless $_, $right } states($left)
when $right {
? grep { hyperless $left, $_ } states($right)
otherwise {
! grep -> $a { grep -> $b { $b < $a } states($right) }
states ($left); }
}
}
Assuming states() on a nonjunction just returns its argument. This
code just gives true or false, not the junction of matching states
like it should.
I think what I have there is right, though I can't be sure.
Luke
Deborah Ariel Pickett
I hear there's a vacancy for a qw(...) equivalent now . . .
No, I'm not really suggesting this. But I am reminded by this whole
endeavour of a certain text adventure.
> get underscore
Taken.
> get bracket
Taken.
> get guillemot
Taken.
> get caret
Taken.
> get backtick
Oops! While you were reaching for the backtick, you drop the guillemot,
and both tumble to the ground.
(Whine: my Perl undergrad students are too young to remember or
appreciate text adventures. At least some of you oldsters here will
understand.)
--
Debbie Pickett http://www.csse.monash.edu.au/~debbiep deb...@csse.monash.edu.au
"Is it, err, Mildred? O.K., no. How 'bout - Diana? Rachel?" "Ariel, her name is
Ariel." - _The Little Mermaid_
Michael Lazzaro
On Thursday, October 31, 2002, at 03:47 PM, Deborah Ariel Pickett
wrote:
> (Whine: my Perl undergrad students are too young to remember or
> appreciate text adventures. At least some of you oldsters here will
> understand.)
Hey! We're not old, we're just version 1.0!
Can we have a "grue" operator? It would be invisible, and eat
everything it operated on. Oh, wait... I think Damian already has that
module.
MikeL
Deborah Ariel Pickett
> Taken.
Extra credit for those of you who remembered that that's a bird, not a
punctuation mark.
Andrew Wilson
> Austin Hastings wrote:
>> traits = any ( ... )
>> requirements = .. & ..
>> if $requirements eq $traits
>>
>> Should that be traits = all()?
>
> No. Because later we say (effectively):
>
> print "True love\n"
> if all(@desiderata) eq any(@traits)
>
> In other words we want *all* the desired characteristics to be matched
> by *some* trait. If the comparison was C<all(...) eq all(...)>, then
> you're asking for every characteristic to be the same as every trait,
> which obviously can't happen.
>
> This is just a case where the "logic" of English phraseology has
> several implicit assumptions that computational logic can't just
> fudge over.
I don't understand this either, but my quibble is where did the all in
the all(@desiderata) come from? Lets see if I've got this straight
a & b is equivalent to all(a, b)
x | y is equivalent to any(x, y)
Yes?
so:
all(a, b) eq any(a, b, c)
should be true because all() of a and b are in the any() list. Yes?
If I'm right about that, I would expect
(a & b) | (c & d) eq any(a, e, g)
to be false because it should try ANY of the two junks (a & b) or
(c & d) the first fails because there is no b and the second fails
because there is no c and no d. I would also expect
(a & b) | (c & d) | g eq any(a, e, g)
to be true because any() of the terms (g in this case) on the left is
fully satisfied by terms on the right. In the original example the
@desiderata is an | junk at the topmost level. I don't see why it
suddenly gets all() wrapped around it. Wouldn't that just be
all[ any< all(), all(), all() > ]
which is the same as
any< all(), all(), all() >
I'm not sure I'm explaining this very well, let me try with the example
that's giving me bother.
$requirements = "tall" & "dark" & "handsome"
| "old" & "rich"
| "Australian";
for <> -> $candidate {
my $traits = any( split /<ws>/, $candidate );
print "True love: $candidate\n"
if $requirements eq $traits;
}
Lets say that $candidate = "tall dark rich Australian", traits then
becomes any("tall", "dark", "rich", "Australian"). So, does
$requirements eq $traits? To me that expands to:
(
(
("tall" eq "tall") or \
("tall" eq "dark") or True because "tall" eq "tall"
("tall" eq "rich") or
("tall" eq "Australian") /
) AND (
("dark" eq "tall") or \
("dark" eq "dark") or True because "dark" eq "dark"
("dark" eq "rich") or
("dark" eq "Australian") /
) AND (
("handsome" eq "tall") or \
("handsome" eq "dark") or False no matches
("handsome" eq "rich") or
("handsome" eq "Australian") /
)
) ***OR*** (
(
("old" eq "tall") or \
("old" eq "dark") or False no matches
("old" eq "rich") or
("old" eq "Australian") /
) AND (
("rich" eq "tall") or \
("rich" eq "dark") or True because "rich" eq "rich"
("rich" eq "rich") or
("rich" eq "Australian") /
)
) ***OR*** (
("Australian" eq "tall") or \
("Australian" eq "dark") or True because "Australian" eq "Australian"
("Australian" eq "rich") or
("Australian" eq "Australian") /
)
Junk 1: "tall" & "dark" & "handsome"
Junk 2: "old" & "rich"
Junk 3: "Australian";
Junk 1 fails because the candidate is not handsome. Junk 2 fails because
the candidate is not old. Junk 3 succeeds because the candidate is
Australian.
This means that the candidate matches overall because junks 1, 2 and 3
are related by | which is any. I don't see how or why you would wrap an
all() around that. There is all()ness going on, but it's represented in
the above by the ands which are in turn grouped with any (the ors).
Why isn't this example
print "True love\n"
if any(@desiderata) eq any(@traits)
Does whether it's any() or all() not depend on what the top level
operator in the junction is? Am I missing something?
andrew
--
Gemini: (May 21 - June 21)
You will be the first one put up against the wall in next week's bloody
revolution in skin care.
John Siracusa
> Damian Conway writes:
>> BTW, Both Larry and I do understand the appeal of interleaving
>> sources and iterators. We did consider it at some length back
>> in January, when we spent a week thrashing this syntax out.
>>
>> Of course, I can't speak for Larry, but in the end I concluded
>> that interleaving iterator variables is a false win, since it
>> trades reduced syntactic complexity for increased semantic
>> complexity, but only really improves the readability of a
>> comparatively rare case.
>>
Yeah, I'd like to hear those details too, because the alternate syntax:
> 1) for @a -> $x ; @b -> $y { ... }
sure looks a lot more attractive and sensible to me, and I agree with all
the arguments in favor of it so far. In particular:
* No "look here, then look there" connection between (possibly) widely
separated items.
* Simple to add or remove/comment-out individual stream/item(s) pairs
without having to "count" what are essentially positional parameters to make
sure you haven't mis-mapped anything in the process.
* More familiar use of the semicolon (IMO)
-John
Luke Palmer
> From: Andrew Wilson <and...@rivendale.net>
> Mail-Followup-To: "perl6-l...@perl.org" <perl6-l...@perl.org>
> Content-Disposition: inline
> X-SMTPD: qpsmtpd/0.12, http://develooper.com/code/qpsmtpd/
>
> On Fri, Nov 01, 2002 at 07:54:01AM +1100, Damian Conway wrote:
> > Austin Hastings wrote:
> >> traits = any ( ... )
> >> requirements = .. & ..
> >> if $requirements eq $traits
> >>
> >> Should that be traits = all()?
> >
> > No. Because later we say (effectively):
> >
> > print "True love\n"
> > if all(@desiderata) eq any(@traits)
> >
> > In other words we want *all* the desired characteristics to be matched
> > by *some* trait. If the comparison was C<all(...) eq all(...)>, then
> > you're asking for every characteristic to be the same as every trait,
> > which obviously can't happen.
> >
> > This is just a case where the "logic" of English phraseology has
> > several implicit assumptions that computational logic can't just
> > fudge over.
>
> I don't understand this either, but my quibble is where did the all in
> the all(@desiderata) come from?
First, I'd like to say that your explanation was immaculate. You
understand junctions perfectly, from what I can tell.
I think Damian was ignoring the the top level any() in order to make
the explanation clearer (or forgot about it ;). Consider it as though
@desiderata contained the (all) states of only one of the (any) states
in his $requirements. I think that's what "(effectively)" meant.
Indeed, worry not. It was just a bit of an oversimplification.
Luke
Larry Wall
: Austin Hastings wrote:
:
: > In the C that I learned, the &^| ops were bitwise.
: >
: > Likewise, the && || ops were lazy booleans.
: >
: > So what's a single-letter boolean act like? Is it lazy? Does it retain
: > its bitwise-ness but (since boolean) force evaluation for 1 or 0 first?
: > I just don't understand what the "implied" behavior is, since the
: > reference is outside my experience.
:
: Since they're producing a boolean result, both C<?&> and C<?|> could be
: implemented lazily. However, I suspect they mightn't be, just to keep
: them consistent (in their evaluation of operands) with the other bitwise
: ops.
What you're saying is correct, except that I don't think we should
be confusing "lazy" with "short-circuit". A lazy operator wouldn't
evaluate *either* side until it jolly well had to. If you say
() = 1..Inf;
it shouldn't even try to produce a 1.
I don't much care whether they short-circuit or not. I could argue it
either way. I think it'd be okay if they short-circuit. Anybody who
uses an operator like ?& expecting it to force a side effect on the
second expression is nuts. And there's something (though not much)
to be said for having an exact equivalent for C's && operator.
Larry
Luke Palmer
Larry wrote:
> I don't much care whether they short-circuit or not. I could argue it
> either way. I think it'd be okay if they short-circuit. Anybody who
> uses an operator like ?& expecting it to force a side effect on the
> second expression is nuts. And there's something (though not much)
> to be said for having an exact equivalent for C's && operator.
Well, would you mind saying it then? Because there's certainly
something to be said against having an exact equivalent for C's &&
operator.
Luke
Simon Cozens
> In general I find backticks fairly jarring on the eyes, but they have to
> be used for _something_ ...
I think ugliness is actually a feature for vector ops. No sense having
to strap your programmers to the mast.
--
In a sense Christianity is like Jazz - if you need to ask the questions
you won't understand the answers.
- Bob Billing
Chris Dutton
The current syntax offers a significant advantage, though. I'm assuming
parser knows to look for equal numbers of things on both sides of
the ->. If we go with the proposed alternate syntax, won't we run into
the problem where it sees:
for @a -> $a; as a complete postfix for loop that just happens to do
nothing?
I suppose the same could be said for the existing syntax. "for @a;"
would look like a loop with the default topic variable. Maybe I'm just
wrong, but the proposed syntax seems to introduce ambiguity by breaking
the for loop up a bit too much, while the current use of the "->" and
semicolons holds the whole thing together.
As for maintaining the sanctity of the semicolon, I would offer that
consistency of the arrow operator is more important.