Re: [RFC] Perl6 HyperOperator List
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. 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 Csystem() 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
Re: [RFC] Perl6 HyperOperator List
On Thu, Oct 31, 2002 at 12:16:34PM +, [EMAIL PROTECTED] 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: 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.
Re: [RFC] Perl6 HyperOperator List
--- Damian Conway [EMAIL PROTECTED] 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 | (510)
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/
Re: [RFC] Perl6 HyperOperator List
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. yes if you demand a prefix a ^(+=) b where ^ can be replaced (almost ) everything . arcadi .
Re: [RFC] Perl6 HyperOperator List
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'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 Call(...) 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
Re: [RFC] Perl6 HyperOperator List
Graham Barr wrote: On Thu, Oct 31, 2002 at 12:16:34PM +, [EMAIL PROTECTED] 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
Re: [RFC] Perl6 HyperOperator List
--- Luke Palmer [EMAIL PROTECTED] wrote: --- Damian Conway [EMAIL PROTECTED] 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 Call(...) 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. 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? 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. =Austin __ Do you Yahoo!? HotJobs - Search new jobs daily now http://hotjobs.yahoo.com/
Re: [RFC] Perl6 HyperOperator List
Oops. About that op thing, I was wrong. Though there is a case 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
Re: [RFC] Perl6 HyperOperator List
Date: Thu, 31 Oct 2002 15:16:17 -0800 (PST)
From: Austin Hastings [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
--- Luke Palmer [EMAIL PROTECTED] wrote:
--- Damian Conway [EMAIL PROTECTED] 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 Call(...) 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.
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?
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.
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
Re: [RFC] Perl6 HyperOperator List
On Thu, Oct 31, 2002 at 12:16:34PM +, [EMAIL PROTECTED] 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_ ... 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 [EMAIL PROTECTED] Is it, err, Mildred? O.K., no. How 'bout - Diana? Rachel? Ariel, her name is Ariel. - _The Little Mermaid_
Re: [RFC] Perl6 HyperOperator List
get guillemot Taken. Extra credit for those of you who remembered that that's a bird, not a punctuation mark. -- Debbie Pickett http://www.csse.monash.edu.au/~debbiep [EMAIL PROTECTED] Is it, err, Mildred? O.K., no. How 'bout - Diana? Rachel? Ariel, her name is Ariel. - _The Little Mermaid_
Re: [RFC] Perl6 HyperOperator List
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
Re: [RFC] Perl6 HyperOperator List
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 Call(...) 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.
Re: [RFC] Perl6 HyperOperator List
Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
Date: Fri, 1 Nov 2002 03:08:37 +
From: Andrew Wilson [EMAIL PROTECTED]
Mail-Followup-To: [EMAIL PROTECTED] [EMAIL PROTECTED]
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 Call(...) 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
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.
Re: [RFC] Perl6 HyperOperator List
On Fri, 1 Nov 2002, Damian Conway wrote: : 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
Re: [RFC] Perl6 HyperOperator List
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
Re: [RFC] Perl6 HyperOperator List
On Tue, 29 Oct 2002, Larry Wall wrote:
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
Re: [RFC] Perl6 HyperOperator List
Larry Wall wrote:
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
Re: [RFC] Perl6 HyperOperator List
On Wed, Oct 30, 2002 at 11:26:01AM -0500, Buddha Buck wrote:
How would you parse:
@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
[EMAIL PROTECTED]
Re: [RFC] Perl6 HyperOperator List
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
RE: [RFC] Perl6 HyperOperator List
Larry Wall writes:
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 .
Re: [RFC] Perl6 HyperOperator List
On Wed, 30 Oct 2002, Austin Hastings wrote:
: [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?
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
: (110) | (510) ?
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
Re: [RFC] Perl6 HyperOperator List
On Wed, 30 Oct 2002, Jonathan Scott Duff wrote: : 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
RE: [RFC] Perl6 HyperOperator List
On Wed, 30 Oct 2002 [EMAIL PROTECTED] wrote:
: Larry Wall writes:
:
: 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 .
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
Re: [RFC] Perl6 HyperOperator List
On Wed, 30 Oct 2002, Michael Lazzaro wrote: : 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
Re: [RFC] Perl6 HyperOperator List
Jonathan Scott Duff writes: 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/
Re: [RFC] Perl6 HyperOperator List
Larry Wall writes: 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
Re: [RFC] Perl6 HyperOperator List
Larry Wall writes: 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. http://training.gbdirect.co.uk/course/perl/
Re: [RFC] Perl6 HyperOperator List
So despite the beauty of 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
RE: [RFC] Perl6 HyperOperator List
On Wed 30 Oct, Larry Wall wrote: 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 Cundef 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 [EMAIL PROTECTED]http://www.waveney.org Telecoms [EMAIL PROTECTED] http://www.WaveneyConsulting.com Web services [EMAIL PROTECTED]http://www.wavwebs.com Independent Telecomms Specialist, ATM expert, Web Analyst Services
Re: [RFC] Perl6 HyperOperator List
Larry Wall wrote: : 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
Re: [RFC] Perl6 HyperOperator List
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).
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).
(110) | (510) ?
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
Re: [RFC] Perl6 HyperOperator List
Brent Dax self-deprecated:
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
Re: [RFC] Perl6 HyperOperator List
Larry wrote: 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 Ctrue and Cfalse constants, we may have Ctrue and Cfalse 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 : (110) | (510) ? 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
Re: [RFC] Perl6 HyperOperator List
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. I think we could also allow a [??] b [::] c But it's not clear whether we can parse a = [undef][...] Larry
