Re: Persistance of superpositions?
Date: Tue, 29 Oct 2002 15:57:56 -0800 (PST) From: Larry Wall [EMAIL PROTECTED] That's not a problem with builtins, but what about sub foo (); sub prefix:foo ($x); @a = [foo][1,2,3,4,5]; So how is this interpreted? Such syntactic ambiguity isn't nice. Should we go with the hyper interpretation, and say use: [foo].[1,2,3,4,5] For the other way. Wait... but that's no good! That's an infinite lookahead situation (is our parser one that cares?): [$foo.baz.bar.assuming(a = 1, b = 2, d = 4)] ^^ term? operator? i don't know. keep on parsing Oh! Operator! I think this ambiguity is prevalent enough to sit with the coder, considering other cases. How are we going to deal with this? Luke
Re: [RFC] Perl6 Operator List, Take 5
On Tue, Oct 29, 2002 at 05:16:48PM -0800, Michael Lazzaro wrote: unary (prefix) operators: \ - reference to * - list flattening ? - force to bool context ! - force to bool context, negate 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 Noe that we have gained ^ back from being a hyeroperator, could we not have ^ as a polymorphic complement operator. It can always be combined with ~ or + to force context, eg $a = ^ +$b; $a = ^ ~$b; We would then have a complement operator that I would assume objects could overload and do whatever they liked with. Graham.
[OT] linguistics and cultural bias?
On Tue, 29 Oct 2002, Larry Wall wrote: Logically entangle nouns *are* more basic than grade school. Kids are even sophisticated enough to disambiguate xor from or by context, despite the fact that English has no xor operator: Which do you want? A popsicle or a Mickey Mouse hat? Hmmm... I've heard that this is a culturally driven thing: that whilst people can all disambiguate it, people from different cultures may do so differently In a western culture, exclusive-or is the assumed default unless context implies otherwise. But in many Pacific island cultures (*), if one offers kava or coffee one would be expected to provide both if answered yes. -Martin (* This from annecdotal memory of 20 years ago, so I don't vouch that it still applies in any particular culture, but the essential point remains that the disambiguation is not as universal or consistent as may seem to us sitting here in Australasia, USA or Europe, speaking English.)
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: Nondeterministic algorithms, flexops, and stuff
On Wed, Oct 30, 2002 at 04:03:55PM +, Piers Cawley wrote: Jonathan Scott Duff [EMAIL PROTECTED] writes: Hey, that's neat. Although it looks like it returns the $src when there isn't a path. You probably want it to return undef or something. Nah, it'll die when there isn't a path. duh! Of course. I was too busy thinking about the recursion. Perhaps where you have die there should be something like $src.collapse or maybe just return undef. Well, traditionally you have 'fail' there, wants to be some kind of exception, but I'm not entirely sure of what the semantics should be. In my very-non-exceptional programming, I'd want undef if there wasn't a path. So, I guess your code is just fine but needs a CATCH block in there. The superposition collapses when it finds a path or finds that there is no path, no backtracking would be required. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Wh[ie]ther Infix Superposition ops
On 29 Oct 2002 at 11:22, Jonathan Scott Duff wrote:
On Tue, Oct 29, 2002 at 10:13:39AM +0200, Markus Laire wrote:
Also the idea of allways using 'function' style for something so
basic like superpositions doesn't appeal to me.
Superpositions are basic in a fabric-of-the-universe kind of way,
but they are hardly basic in the everyone-learns-them-in-grade-school
kind of way. I think the latter is more important for huffman coding
of operators for the unwashed masses. But I'm willing change my mind
if we start teaching everyone superpositions in grade school :-)
You are making the fundamental mistake of thinking superpositions as
superpositions. When thinking them as another-kind-of or/and, their
usefulness comes a lot clearer.
perl5: if $x == 5 || $x == 7 || $x == 99
perl6: if $x == 5 | 7 | 99
perl5: ...loop to test every value in an array...
perl6: if ! 28 = any(@days_in_months) = 31 { ERROR }
(this probably has slight syntax error)
perl5: if $x 0 $x 20 $y 0 $y 20 $z 0 $z 20
perl6: if 0 $x $y $z 20
perl5: if ($x = 10 $x = 20) || ($x = 30 $x = 40)
perl6: if $x ~~ 10..20 | 30..40
--
Markus Laire 'malaire' [EMAIL PROTECTED]
Re: Wh[ie]ther Infix Superposition ops
On Wednesday, October 30, 2002, at 07:18 AM, Jonathan Scott Duff wrote: The only thing this inspires in my brain is Schoolhouse Rock flashbacks. o/~ Conjuction Junction, what's your function? o/~ Heh. That's what I heard, too. David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [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 Operator List, Take 5
[.]foo() # What does this mean? One could argue that several ways, depending on what's in the current topic. It's the exact same thing as the binary form of dot, but with the left side being implied, as 'the current topic': topic is a scalar: hyperdot does nothing (scalar hyperop scalar == scalar op scalar) topic is a listref: listref is automatically dereferenced, foo method is called on all elements. (In other words, I imagine calling a hyper on scalars is not an error -- it just doesn't do anything more interesting than the normal op.) Note you could also perhaps say something like [.]$methodlist() to mean call each of these methods on (each of) the current topic(s), tho I'm not sure the syntax is accurate there. MikeL
worth adding collections to the core language?
In the Re: Wh[ie]ther Infix Superposition ops thread
On Wed, 30 Oct 2002, Piers Cawley wrote:
But given a decent Collection hierarchy:
my $seen = Set.new($start,$finish);
for - $next {
print $next unless $next =~ $seen;
$seen.insert($next);
}
Just a thought...are sets (or other Collection types) something that we
use often enough that they would deserve to be in the core language? I
know I've used hashes as no-repeats-allowed sets many times, so clearly
they are commonly useful. On the other hand, since this can be done,
maybe there is no need to implement a new core feature for them.
I suspect the answer is no, we don't need them but I just thought I'd
ask; I'm curious about the design reasons either way.
--Dks
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: worth adding collections to the core language?
On Wed, 30 Oct 2002, Dave Storrs wrote:
: In the Re: Wh[ie]ther Infix Superposition ops thread
:
: On Wed, 30 Oct 2002, Piers Cawley wrote:
:
: But given a decent Collection hierarchy:
:
: my $seen = Set.new($start,$finish);
:
: for - $next {
: print $next unless $next =~ $seen;
: $seen.insert($next);
: }
:
: Just a thought...are sets (or other Collection types) something that we
: use often enough that they would deserve to be in the core language? I
: know I've used hashes as no-repeats-allowed sets many times, so clearly
: they are commonly useful. On the other hand, since this can be done,
: maybe there is no need to implement a new core feature for them.
:
: I suspect the answer is no, we don't need them but I just thought I'd
: ask; I'm curious about the design reasons either way.
The set features are a side effect of junctions, just as they're a side
effect of hashes. An any junction might well be implemented underneath
as a hash without values.
Possibly we might even extend the notion of hash to any junk.
%hash = 1 | 2 | 3;
Then it's clearer that something junctional is going on when you say:
if $val ~~ %hash
I could see % becoming the sigil of choice for junks just for the
documentational value.
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: Nondeterministic algorithms, flexops, and stuff
Jonathan Scott Duff [EMAIL PROTECTED] writes:
On Wed, Oct 30, 2002 at 04:03:55PM +, Piers Cawley wrote:
Jonathan Scott Duff [EMAIL PROTECTED] writes:
Hey, that's neat. Although it looks like it returns the $src when there
isn't a path. You probably want it to return undef or something.
Nah, it'll die when there isn't a path.
duh! Of course. I was too busy thinking about the recursion.
Perhaps where you have die there should be something like
$src.collapse or maybe just return undef.
Well, traditionally you have 'fail' there, wants to be some kind of
exception, but I'm not entirely sure of what the semantics should
be.
In my very-non-exceptional programming, I'd want undef if there wasn't
a path. So, I guess your code is just fine but needs a CATCH block
in there. The superposition collapses when it finds a path or finds
that there is no path, no backtracking would be required.
Tell you what, here's a non flexop translation of the Lisp code I
borrowed my example from. Assume for a moment that Perl has
call_with_current_continuation (it should have *something* like it...)
my @paths;
sub choose(*@choices) {
fail unless @choices;
call_with_current_continuation - $cc {
push @paths, sub { $cc( choose @choices[[EMAIL PROTECTED]] ) };
}
}
sub fail {
return Exhausted Choices but false unless @paths;
my $p1 = pop @choices;
$p1.();
}
sub descent($src, $dst) {
when $src == $dst { return $dst }
when !$src.kids { fail }
otherwise { return $src, descent(choose($src.kids), $dst) }
}
Actually, doing things this way allows one to control whether one
searchs depth or breadth first. For breadth first, just change the
'push' in choose to an unshift...
--
Piers
It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite.
-- Jane Austen?
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: worth adding collections to the core language?
Dave Storrs [EMAIL PROTECTED] writes:
In the Re: Wh[ie]ther Infix Superposition ops thread
On Wed, 30 Oct 2002, Piers Cawley wrote:
But given a decent Collection hierarchy:
my $seen = Set.new($start,$finish);
for - $next {
print $next unless $next =~ $seen;
$seen.insert($next);
}
Just a thought...are sets (or other Collection types) something that we
use often enough that they would deserve to be in the core language? I
know I've used hashes as no-repeats-allowed sets many times, so clearly
they are commonly useful. On the other hand, since this can be done,
maybe there is no need to implement a new core feature for them.
I suspect the answer is no, we don't need them but I just thought I'd
ask; I'm curious about the design reasons either way.
Personally, I'd love to see something like the whole Smalltalk
Collection hierarchy available complete with Bags, Sets, Dictionaries,
OrderedCollections and the whole deal. I note, for instance that
Christian Lemburg has implemented Set::Object, and it's substantially
faster than a hash based implementation for insertion, and marginally
faster for lookup. See
http://search.cpan.org/author/JLLEROY/Set-Object-1.02/Object.pm#PERFORMANCE
for Christian's numbers. I would hope that we could see other
performance gains for other Collection classes.
Taking a quick glance at a handy Smalltalk image, it seems that,
ideally one would want to have Collections in the core so that Hash
could inherit from Collection via Set. But then, anything's possible
at compile time, so one could probably set something appropriate up by
doing 'use Collections'.
--
Piers
It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite.
-- Jane Austen?
Re: worth adding collections to the core language?
Piers Cawley [EMAIL PROTECTED] writes: Personally, I'd love to see something like the whole Smalltalk Collection hierarchy available complete with Bags, Sets, Dictionaries, OrderedCollections and the whole deal. I note, for instance that Christian Lemburg has implemented Set::Object, and ^ That's Jean-Louis Leroy, obviously. Brainfade. -- Piers It is a truth universally acknowledged that a language in possession of a rich syntax must be in need of a rewrite. -- Jane Austen?
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: worth adding collections to the core language?
On Wed, 30 Oct 2002, Piers Cawley wrote: :It is a truth universally acknowledged that a language in : possession of a rich syntax must be in need of a rewrite. : -- Jane Austen? It is a truth universally acknowledged that a language in possession of a rich syntax must be in need of a larger character set. I can almost taste it: French quotes for hyperoperators... a «+» b a«++» a«.anymethod(args)» Larry
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 Operator List, Take 5
--- Jonathan Scott Duff [EMAIL PROTECTED] wrote:
On Wed, Oct 30, 2002 at 09:13:02AM -0800, Austin Hastings wrote:
--- Jonathan Scott Duff [EMAIL PROTECTED] wrote:
Maybe we've gone over this before but, if so, I don't remember
...
On Tue, Oct 29, 2002 at 05:16:48PM -0800, Michael Lazzaro wrote:
hyperoperators:
[op] - as prefix to any unary/binary operator, vectorizes
the
operator
. - method call on current topic
What would [.]method() mean?
@a = @b[.]method(); # Sets each @a[x] to @b[x].method()
No, no. I'm talking about the unary . prefix
method blah {
.foo()
[.]foo() # What does this mean?
}
Vector of invocations of the foo methods of the current topic.
Presumably you'd have an array in topic, or you'd use it in an array
context.
for @lol - @onelist {
@a = [.]foo();
}
=Austin
__
Do you Yahoo!?
HotJobs - Search new jobs daily now
http://hotjobs.yahoo.com/
Re: [RFC] Perl6 Operator List, Take 5
On Wed, 30 Oct 2002, Austin Hastings wrote:
: No, no. I'm talking about the unary . prefix
:
: method blah {
: .foo()
: [.]foo() # What does this mean?
: }
:
: Vector of invocations of the foo methods of the current topic.
Except that the topic is by definition singular in a method, and so
is a method name. So it'd be no different from ordinary dot. Maybe
it's an error to use a vector op on two scalars.
: Presumably you'd have an array in topic, or you'd use it in an array
: context.
:
: for lol - onelist {
:a = [.]foo();
: }
Yes, that would work, though I'd love to see it:
for lol - onelist {
a = «.»foo();
}
instead. Maybe ^[+] (or whatever) is just a workaround for people
who can't figure out how to write «+». I love the shimmers on
either side of the operator. That's a nice plural visual metaphor.
I'd even be willing to give up «foo bar baz» meaning qw(foo bar baz)
for this.
Larry
Re: Iterators [was: worth adding collections to the core language?]
Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
Cc: [EMAIL PROTECTED] [EMAIL PROTECTED]
From: Piers Cawley [EMAIL PROTECTED]
Date: Wed, 30 Oct 2002 18:59:15 +
X-SMTPD: qpsmtpd/0.12, http://develooper.com/code/qpsmtpd/
Dave Storrs [EMAIL PROTECTED] writes:
In the Re: Wh[ie]ther Infix Superposition ops thread
On Wed, 30 Oct 2002, Piers Cawley wrote:
But given a decent Collection hierarchy:
my $seen = Set.new($start,$finish);
for - $next {
print $next unless $next =~ $seen;
$seen.insert($next);
}
Just a thought...are sets (or other Collection types) something that we
use often enough that they would deserve to be in the core language? I
know I've used hashes as no-repeats-allowed sets many times, so clearly
they are commonly useful. On the other hand, since this can be done,
maybe there is no need to implement a new core feature for them.
I suspect the answer is no, we don't need them but I just thought I'd
ask; I'm curious about the design reasons either way.
Personally, I'd love to see something like the whole Smalltalk
Collection hierarchy available complete with Bags, Sets, Dictionaries,
OrderedCollections and the whole deal. I note, for instance that
Christian Lemburg has implemented Set::Object, and it's substantially
faster than a hash based implementation for insertion, and marginally
faster for lookup. See
http://search.cpan.org/author/JLLEROY/Set-Object-1.02/Object.pm#PERFORMANCE
for Christian's numbers. I would hope that we could see other
performance gains for other Collection classes.
Well, to generalize the notion of array and hash wouldn't be that
difficult. Change them, respectively, to ordered and unordered.
I wonder if @things should have a more general interface than
numerical indices. I've wanted linked lists in perl, and every time I
do a splice on an array I cringe for speed reasons.
Heh, we could use my linked array implementation. Or not.
But I think we need a concept of iterators in the core. I like the
C++ STL because of it's generalization of iterators. I think it's
worth repeating, rantexcept the part about declaring them taking a
page of code:
listactor::id_type::const_reverse_iterator = idlist.rbegin();
That's more hideous than anything Perl haters yell about. At least
perl does something. I mean, in that many Perl characters people have
made computer algebra systems ;)
/rant
So lets see, ... derefrences and increments its prisoner. Perhaps
just ++ing and --ing would work. Of course, I'd hate to use $iter--
for a derefrence without an increment. Or, yes, of course! Would it
be possible to overload prefix:$ ? Then we could derefrence with the
derefrence operator $$iter.
Um, yeah, my mind is kinda scattered. Just a little bit.
Luke
Re: [RFC] Perl6 Operator List, Take 5
--- Larry Wall [EMAIL PROTECTED] wrote:
On Wed, 30 Oct 2002, Austin Hastings wrote:
: No, no. I'm talking about the unary . prefix
:
:method blah {
: .foo()
: [.]foo() # What does this mean?
:}
:
: Vector of invocations of the foo methods of the current topic.
Except that the topic is by definition singular in a method, and so
is a method name. So it'd be no different from ordinary dot. Maybe
it's an error to use a vector op on two scalars.
method blah()
{
@values = [.]@list_of_methods(); # Are method pointers meaningful?
}
: Presumably you'd have an array in topic, or you'd use it in an
array
: context.
:
: for @lol - @onelist {
:@a = [.]foo();
: }
Yes, that would work, though I'd love to see it:
for @lol - @onelist {
@a = «.»foo();
}
How do you write a « in a Windows based environment? (Other than by
copying them from Larry's emails or loading MSWord to do
insert-symbol)
instead. Maybe ^[+] (or whatever) is just a workaround for people
who can't figure out how to write «+». I love the shimmers on
either side of the operator. That's a nice plural visual metaphor.
Yeah, This looks kind of fuzzy. You probably don't clearly see what's
going on. Works for me.
I'd even be willing to give up «foo bar baz» meaning qw(foo bar baz)
for this.
Holy rat-on-a-stick, Batman! That IS quite a sacrifice...
=Austin
__
Do you Yahoo!?
HotJobs - Search new jobs daily now
http://hotjobs.yahoo.com/
Re: [RFC] Perl6 Operator List, Take 5
On Wednesday, October 30, 2002, at 11:58 AM, Larry Wall wrote: I'd even be willing to give up ´foo bar bazª meaning qw(foo bar baz) for this. I can't see that right (MacOSX Jaguar) in the email; to me it looks like a forwardtick and an, um, underlined 'a' -- but in spite of that, I'm game. It's just so pretty (when it works!) On my Mac, it's spelled «op» -- can others see that correctly, or do we have a sorry disconnect in the fonts, here, for us Mac folks? MikeL
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 Operator List, Take 5
On Wednesday, October 30, 2002, at 12:17 PM, Michael Lazzaro wrote: I can't see that right (MacOSX Jaguar) in the email; to me it looks like a forwardtick and an, um, underlined 'a' -- but in spite of that, I'm game. It's just so pretty (when it works!) On my Mac, it's spelled «op» -- can others see that correctly, or do we have a sorry disconnect in the fonts, here, for us Mac folks? I use Mail.app, and saw the same thing you did. When I looked at the headers for Larry's email, I saw: Content-Type: text/plain; charset=UTF-8; But when I saw yours, you had: Content-Type: text/plain; charset=ISO-8859-1; format=flowed This tells me that Mail.app, for some reason, didn't know that it was supposed to use UTF-8 when showing Larry's mail. When I pasted his mail into a UTF-8 document in Emacs, it looked fine. Given that it's probably UTF-8 that Perl 6 source code is written in, I think that you and I might be better off using a smarter mailer. David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: [RFC] Perl6 Operator List, Take 5
On 2002-10-30 at 12:23:53, David Wheeler wrote: This tells me that Mail.app, for some reason, didn't know that it was supposed to use UTF-8 when showing Larry's mail. When I pasted his mail into a UTF-8 document in Emacs, it looked fine. Given that it's probably UTF-8 that Perl 6 source code is written in, I think that you and I might be better off using a smarter mailer. David Larry's mail was *marked* as UTF-8, but by the time I got it it had no French quotes in it in UTF-8, Latin-1, or any other encoding anymore. My mailer understand UTF-8 just fine, and so does vim (which I used to look at my spool file to check for encoding oddities); in my copy of his message, there's just nothing there. All I can think is that some MTA along the way - possibly our very own Exchange server - stripped them out. -- Mark REED| CNN Internet Technology 1 CNN Center Rm SW0831G | [EMAIL PROTECTED] Atlanta, GA 30348 USA | +1 404 827 4754
Re: Vectorizing operators for Hashes
Proposal : Vector operations for Hashes
%a ^{+} %b
the direct generalization would be as follows :
a ^[op] b
for a ; b -
$x ; $y {
$x op $y
}
%a op %b
# find common keys
k = keys hash{ map { { _=1 } } *( %a.keys , %b.keys ) };
#return hash
hash {
for k - $x {
{ $x = %a{$x} op %b{$x} }
}
}
so in words , find coomon keys and then vectorize op as if
hash keys are array indexes.
Probably that behaviour may be tuned or conrolled by properties of
hashes just like what happens inside regexes .
maybe this could be made more general , since
Larry noted that junctions ( 1 | 2 | 3 ) are similar to hashes
%hash = ( 1 | 2 | 3 ) ;
dont have any Idea how.
arcadi.
Re: Vectorizing operators for Hashes
On Wed, 30 Oct 2002 [EMAIL PROTECTED] wrote:
: # find common keys
: @k = keys hash{ map { { _=1 } } *( %a.keys , %b.keys ) };
It seems a bit odd to privilege the intersection over the union.
Larry
Re: Wh[ie]ther Infix Superposition ops
On Wed, Oct 30, 2002 at 06:45:52PM +0200, Markus Laire wrote: You are making the fundamental mistake of thinking superpositions as superpositions. When thinking them as another-kind-of or/and, their usefulness comes a lot clearer. perl5: if $x 0 $x 20 $y 0 $y 20 $z 0 $z 20 perl6: if 0 $x $y $z 20 I find that really quite confusing written like that. but like this if 0 ($x $y $z) 20 it makes more sense to me. What's the precedence? Although as regular user of numerical bitops in C, I find it visually jarring that isn't what it means in C, C++, perl and most other current languages. Nicholas Clark -- Brainfuck better than perl? http://www.perl.org/advocacy/spoofathon/
Re: Vectorizing operators for Hashes
!! Sorry, in previos post I had a mistake
Proposal : Vector operations for Hashes
(
this is just a joke
%a ^{+} %b
)
the direct generalization would be as follows :
a ^[op] b
for a ; b -
$x ; $y {
$x op $y
}
%a ^[op] %b
# find common keys
k = keys hash{ map { { _=1 } } *( %a.keys , %b.keys ) };
#return hash
hash {
for k - $x {
{ $x = %a{$x} op %b{$x} }
}
}
so in words , find common keys and then vectorize op as if
hash keys are array indexes.
Probably that behaviour may be tuned or conrolled by properties of
hashes just like what happens inside regexes .
maybe this could be made more general , since
Larry noted that junctions ( 1 | 2 | 3 ) are similar to hashes
%hash = ( 1 | 2 | 3 ) ;
dont have any Idea how.
arcadi.
plaintive whine about 'for' syntax
In a different thread, Buddha Buck wrote the following code snippet:
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
Re: [RFC] Perl6 Operator List, Take 5
On 30/10/02 15:33 -0500, Mark J. Reed wrote: On 2002-10-30 at 12:23:53, David Wheeler wrote: This tells me that Mail.app, for some reason, didn't know that it was supposed to use UTF-8 when showing Larry's mail. When I pasted his mail into a UTF-8 document in Emacs, it looked fine. Given that it's probably UTF-8 that Perl 6 source code is written in, I think that you and I might be better off using a smarter mailer. David Larry's mail was *marked* as UTF-8, but by the time I got it it had no French quotes in it in UTF-8, Latin-1, or any other encoding anymore. My mailer understand UTF-8 just fine, and so does vim (which I used to look at my spool file to check for encoding oddities); in my copy of his message, there's just nothing there. All I can think is that some MTA along the way - possibly our very own Exchange server - stripped them out. Wait. So you mean that a French quote isn't a question mark? I take back all those things I've said about the French in the last 24 hours. Cheers, Brian
Re: plaintive whine about 'for' syntax
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
RE: [RFC] Perl6 Operator List, Take 5
On 29 Oct 2002 at 22:29, Larry Wall wrote:
Of course, Real Mathematicians will want [1..10) and (1..10] instead.
That seems familiar, I like it ;)
There's also an issue of what (1..10) - 1 would or should mean, if
anything. Does it mean (1..9)? Does 1 + (1..10) mean (2..10)?
And what would ('a' .. 'z') - 1 mean?
If we are going to do math with ranges, we definitely need non-
discreet ranges also. Or at least make sure it's easy enough to
implement as a class.
(1.9 .. 2.1) + (5..7) * (72.49 .. 72.51);
--
Markus Laire 'malaire' [EMAIL PROTECTED]
Re: Wh[ie]ther Infix Superposition ops
On Wed, 30 Oct 2002, Nicholas Clark wrote:
: On Wed, Oct 30, 2002 at 06:45:52PM +0200, Markus Laire wrote:
:
: You are making the fundamental mistake of thinking superpositions as
: superpositions. When thinking them as another-kind-of or/and, their
: usefulness comes a lot clearer.
:
: perl5: if $x 0 $x 20 $y 0 $y 20 $z 0 $z 20
: perl6: if 0 $x $y $z 20
:
: I find that really quite confusing written like that. but like this
:
:if 0 ($x $y $z) 20
:
: it makes more sense to me. What's the precedence?
The parens aren't required, but they certainly do help the readability there.
: Although as regular user of numerical bitops in C, I find it visually jarring
: that isn't what it means in C, C++, perl and most other current languages.
That may well be part of why it's hard for us to group it visually
the other way. But I really don't think we want to require parens on:
if $x == 1 | 2 | 3 {...}
Larry
Re: [RFC] Perl6 Operator List, Take 5
On Wed, Oct 30, 2002 at 03:33:57PM -0500, Mark J. Reed wrote: On 2002-10-30 at 12:23:53, David Wheeler wrote: This tells me that Mail.app, for some reason, didn't know that it was supposed to use UTF-8 when showing Larry's mail. When I pasted his mail into a UTF-8 document in Emacs, it looked fine. Given that it's probably UTF-8 that Perl 6 source code is written in, I think that you and I might be better off using a smarter mailer. David Larry's mail was *marked* as UTF-8, but by the time I got it it had no French quotes in it in UTF-8, Latin-1, or any other encoding anymore. My mailer understand UTF-8 just fine, and so does vim (which I used to look at my spool file to check for encoding oddities); in my copy of his message, there's just nothing there. All I can think is that some MTA along the way - possibly our very own Exchange server - stripped them out. At the risk of getting very boring: Larry's message: Content-Type: TEXT/PLAIN; charset=UTF-8 Content-Transfer-Encoding: 8BIT but the body had literal 8 bit Latin 1 «+» So the headers were not correct, as far as my mutt thinks, and it showed me a question mark. Austin Hastings' message: Content-Type: text/plain; charset=us-ascii but the body had literal 8 bit Latin 1 «+» So the headers were also not correct. Michael Lazzaro's message: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable body contains =ABop=BB which my mutt happily displays as «op» His headers accurately describe the body. I don't know what my mutt is going to do outgoing with this message. Clearly 8 bit is even more troublesome for mailers than whitespace. So maybe its a bad thing to use for a language. *However*, based on previous experience, I do know that literal ASCII bel characters: do pass quite successfully from 7 bit ASCII to EBCDIC and back again during their travels. Maybe we can use them for something :-) Nicholas Clark -- C++ templates better than perl? http://www.perl.org/advocacy/spoofathon/
Re: [RFC] Perl6 Operator List, Take 5
On Wed, 30 Oct 2002, Mark J. Reed wrote: : Larry's mail was *marked* as UTF-8, but by the time I got it it : had no French quotes in it in UTF-8, Latin-1, or any other encoding anymore. : My mailer understand UTF-8 just fine, and so does vim (which I used to : look at my spool file to check for encoding oddities); in my copy of his : message, there's just nothing there. All I can think is that some MTA : along the way - possibly our very own Exchange server - stripped them out. If no one saw them then it could well be a problem on my end. I'm trying to use a mailer (pine) that doesn't know about UTF-8 in an environment where vim does UTF-8. And I may have been in a UTF-8 window at the time. Things could easily get screwed up between them. (Anybody know of a version of pine that does UTF-8?) This is currently running in a window that does Latin-1 rather than UTF-8. Do these French quotes come through? a «+» b Larry
Re: plaintive whine about 'for' syntax
Michael Lazzaro writes:
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
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
Re: [RFC] Perl6 Operator List, Take 5
On Wed, Oct 30, 2002 at 11:10:54PM +0200, Markus Laire wrote: If we are going to do math with ranges, we definitely need non- discreet ranges also. Or at least make sure it's easy enough to implement as a class. (1.9 .. 2.1) + (5..7) * (72.49 .. 72.51); I don't think that non-discrete ranges is what you mean. Perhaps you just want ranges whose step size is something other than 1 (1.9 .. 2.1 : 0.1) + (5..7) * (72.49 .. 72.51 : 0.01) ? -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: [RFC] Perl6 Operator List, Take 5
--- Larry Wall [EMAIL PROTECTED] wrote: Do these French quotes come through? @a «+» @b Oui, M'sieu! __ Do you Yahoo!? HotJobs - Search new jobs daily now http://hotjobs.yahoo.com/
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 Operator List, Take 5
On Wednesday, October 30, 2002, at 12:47 PM, Larry Wall wrote: This is currently running in a window that does Latin-1 rather than UTF-8. Do these French quotes come through? @a ´+ª @b Nope. But given that I don't even know where to go to type them in, and doing so will likely be a PITA...even though I *love* the idea of using these characters, might it be better to abandon them for now? Regards, David PS: What do they look like in this reply? -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
plaintive whine about 'for' syntax
Dave Storrs writes:
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 .
Re: [RFC] Perl6 Operator List, Take 5
On Wed, Oct 30, 2002 at 01:25:44PM -0800, Austin Hastings wrote: --- Larry Wall [EMAIL PROTECTED] wrote: Do these French quotes come through? @a «+» @b Odd, I see them in this message. But In the message from Larry I see ?'s Graham.
Re: [RFC] Perl6 Operator List, Take 5
On Wednesday, October 30, 2002, at 01:28 PM, David Wheeler wrote: But given that I don't even know where to go to type them in, and doing so will likely be a PITA...even though I *love* the idea of using these characters, might it be better to abandon them for now? Oh, don't say that! I already know what all of these should mean! :-) ≈ … ∫ § ¿ ∆ ∑ Ω ø ¶ º ≠ ≤ ≥ ‹ › ‡ Ø ˇ ¬ Ç Œ ∞ ¡ • MikeL
Re: [RFC] Perl6 Operator List, Take 5
On Wednesday, October 30, 2002, at 01:35 PM, Graham Barr wrote: On Wed, Oct 30, 2002 at 01:25:44PM -0800, Austin Hastings wrote: --- Larry Wall [EMAIL PROTECTED] wrote: Do these French quotes come through? @a «+» @b Odd, I see them in this message. But In the message from Larry I see ?'s And I didn't see them in Austin's message, but I see them in yours. Your mailer did the right thing, it looks like. David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: plaintive whine about 'for' syntax
On Wed, 30 Oct 2002, Michael Lazzaro wrote:
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?
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
Re: plaintive whine about 'for' syntax
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?
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
Re: [RFC] Perl6 Operator List, Take 5
On Wednesday, October 30, 2002, at 01:43 PM, Michael Lazzaro wrote: Oh, don't say that! I already know what all of these should mean! :-) ≈ … ∫ § ¿ ∆ ∑ Ω ø ¶ º ≠ ≤ ≥ ‹ › ‡ Ø ˇ ¬ Ç Œ ∞ ¡ • Nice, I can see all of those. Your mailer is the same as mine, Apple Mail, and the headers are: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Which is correct. But let me ask you -- how did you input those characters? David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
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 Operator List, Take 5
On Wednesday, October 30, 2002, at 01:46 PM, David Wheeler wrote: But let me ask you -- how did you input those characters? Applications/Utilities/Key Caps (Again, OSX) which shows you where they all are. The «» quotes, for example, are option-\ and shift-option-\ :-) MikeL
Re: plaintive whine about 'for' syntax
On Wed, 30 Oct 2002, Austin Hastings wrote:
--- Dave Storrs [EMAIL PROTECTED] 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
Re: Perl6 Operator List, Damian's take
On Tue, 29 Oct 2002, Austin Hastings wrote: Any of you OO guys know of a case where $a = $a + $b; # A [+]= B; -- A = A [+] B; and $a += $b; # A [+=] B; should be different? They are different in the scalar [op] list case, as explained here: http://archive.develooper.com/perl6-language%40perl.org/msg10961.html ($a = 0) [+=] b; # sum ($a = 1) [*=] b; # product ($a ='') [~=] b; # cat ~ John Williams
Re: plaintive whine about 'for' syntax
On Wed, 30 Oct 2002, Michael Lazzaro wrote:
: 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?
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
Re: plaintive whine about 'for' syntax
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
Re: plaintive whine about 'for' syntax
Wednesday 30 October 2002 22:08, Michael Lazzaro escribió:
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
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
Re: plaintive whine about 'for' syntax
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
Re: worth adding collections to the core language?
On 30 Oct 2002 at 11:09, Larry Wall wrote: On Wed, 30 Oct 2002, Piers Cawley wrote: :It is a truth universally acknowledged that a language in : possession of a rich syntax must be in need of a rewrite. : -- Jane Austen? It is a truth universally acknowledged that a language in possession of a rich syntax must be in need of a larger character set. I can almost taste it: French quotes for hyperoperators... @a «+» @b @a«++» @a«.anymethod(args)» And you could always have something else as a backup for those unfortunates who can't use «+» - like ^[+] What are the good reasons not to use «» ? -- Markus Laire 'malaire' [EMAIL PROTECTED]
Re: Perl6 Operator List, Damian's take
On Wed, 30 Oct 2002, John Williams wrote: : They are different in the scalar [op] list case, as explained here: : http://archive.develooper.com/perl6-language%40perl.org/msg10961.html : : ($a = 0) [+=] b; # sum : ($a = 1) [*=] b; # product : ($a ='') [~=] b; # cat That's almost a reduce. Pity you have to include a variable. But since rvalues are illegal on the left side of an assignment, we *could* go as far as to say that 0 [+=] b; # sum 1 [*=] b; # product '' [~=] b; # cat dwim into reduce operators rather than being illegal. Larry
Re: worth adding collections to the core language?
On Thu, 31 Oct 2002, Markus Laire wrote: : And you could always have something else as a backup for those : unfortunates who can't use «+» - like ^[+] : : What are the good reasons not to use «» ? It would force everyone to get their act together with respect to Unicode. Oh, wait, that's a feature... Larry
Re: plaintive whine about 'for' syntax
Dave Storrs writes:
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
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
Re: plaintive whine about 'for' syntax
On Wed, Oct 30, 2002 at 01:57:00PM -0800, Dave Storrs wrote: *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.
Re: [RFC] Perl6 Operator List, Take 5
On 30 Oct 2002 at 15:24, Jonathan Scott Duff wrote: On Wed, Oct 30, 2002 at 11:10:54PM +0200, Markus Laire wrote: If we are going to do math with ranges, we definitely need non- discreet ranges also. Or at least make sure it's easy enough to implement as a class. (1.9 .. 2.1) + (5..7) * (72.49 .. 72.51); I don't think that non-discrete ranges is what you mean. Perhaps you just want ranges whose step size is something other than 1 (1.9 .. 2.1 : 0.1) + (5..7) * (72.49 .. 72.51 : 0.01) That would also be usefull, but I definitely mean math with non-discrete ranges. How else are you going to calculate with numbers which have 'uncertainty-range' (not sure about right term) i.e. all math in physics. There are bound to be other uses. This should probably be a class, so only problem is then to be sure that it's possible to create such a class and use it with easy syntax. Then there is a question of what such expressions should return. A superposition of non-discrete anges encompassing all the possible solutions would be the easy way. Adding probability distributions to those ranges would also be usefull. Still this is an implementation detail. -- Markus Laire 'malaire' [EMAIL PROTECTED]
Re: Wh[ie]ther Infix Superposition ops
-- On Wed, 30 Oct 2002 07:13:40 Damian Conway wrote: Yes. That superpositions are going to be so widely used once people catch on, that users going to curse us every time they have to write Cuse ops ':superpositions'; at the start of every scope. So, I open my inbox and see that it has been stuffed with Perl 6 language. It's like a little gift. :-) But then I see this debate over the use of superpositions. If there are those who are still disbelieving then go look at the prior art. Icon is a fine little programming language (though a little too pretty for my tastes) that uses very similar syntax to what were talking about here. The big difference is that Icon supports loads of (very nice and clean) backtracking. | and are Icon's || and , but Icon's backtracking gives us a really cool idiom. Superpositions offer us the same thing in Perl 6. Take a look at Icon over at http://www.cs.arizona.edu/icon/ . Once I saw it I did a Piers: This is something I want in Perl and I want it right now! ;-) Damian Get 25MB of email storage with Lycos Mail Plus! Sign up today -- http://www.mail.lycos.com/brandPage.shtml?pageId=plus
Re: Persistance of superpositions?
Brian Ingerson wrote: Not quite. You also need to discriminate the *type* of the superposition: Oh right. I was thinking that Cany and friends were operations, not types. Oops. YAML type-URIs are made up of a type-family with an optional format: !domain.com/type#format and: !int is shorthand for: !yaml.org/int#dec So I'm wondering if any|all|one|none can be formats of !super? I guess so. But they're not really formats, so much as distinct types. And if so, should there be a default format? No. # !yaml.org/any letters: !any [a, b, c] Good. # !yaml.org/super#all digits: !super#all - 0 - 1 - 2 Bad. # !perl.yaml.org/one (Perl specific types) names: !perl/one [Brian, Ingy, Mr Inline] # (Yes, this dwims :) Ugly. (And it would probably have to be !perl6/one) # !perl.yaml.org/super-none (longer type name, no format) sane: !perl/super-none - Larry - Damian - Brian ... Urk. It might be more forward thinking to allow any|all|one|none into the yaml.org type repository. That's my view. Danmian
Re: [RFC] Perl6 Operator List, Take 5
Larry mused: On Tue, 29 Oct 2002, David Whipp wrote: : Larry Wall [mailto:larry;wall.org] wrote: : : unary (postfix) operators: : :... - [maybe] same as ..Inf [Damian votes Yes] : : I wonder if we can possibly get the Rubyesque leaving out of : endpoints by saying something like 1..!10. : Of course, ..! and ..^ have the same problem. But it just seems like it's really unlikely that someone would use a unary ! or ^ on the endpoint term. So with 1..!$x or 1..^$x it's likely to be right if we guess (per the longest token rule) that the operator is ..! or ..^. The same can't be said of .., alas. But at least it might produce a syntax error when it tries to parse the . Of course, Real Mathematicians will want [1..10) and (1..10] instead. I kind like ..^ the best because ^ is currently read exclusive of anyway, sort of... And the arrow can be read up to, at least on that end of it. I think that ..^ is going to be much, much more common than ^.. will be. Forgive me but is this syntax really necessary. Does it buy us enough over +1 and -1? Proposed Now 1..101..10 1..^10 1..9 1..^$x 1..$x-1 1^..10 2..10 $x^..10 $x+1..10 1^..^10 2..9 $x^..^$y $x+1..$y-1 I mean, for what it is, I do like the syntax, but is it useful enough to warrant the extra cognitive load it brings with it? Damian
Re: plaintive whine about 'for' syntax
[EMAIL PROTECTED] (Dave Storrs) writes: 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.
Re: [RFC] Perl6 Operator List, Take 5
Graham Barr wrote: Now that we have gained ^ back from being a hyeroperator, could we not have ^ as a polymorphic complement operator. It can always be combined with ~ or + to force context, eg $a = ^ +$b; $a = ^ ~$b; We would then have a complement operator that I would assume objects could overload and do whatever they liked with. In creating my operator list I deliberated shied away from the unary and binary multimorphic forms. But I do see Graham's point and would favour retaining polymorphic unary C^ at least. Damian
RE: [RFC] Perl6 Operator List, Take 5
Larry Wall:
# This is currently running in a window that does Latin-1
# rather than UTF-8. Do these French quotes come through?
#
# @a + @b
No, but I'm running Outlook, so it's probably a bug on my end. :^) (It
does show up in that annoying variable-width font it switches to for
displaying UTF-8, though.)
--Brent Dax [EMAIL PROTECTED]
@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)
Re: [RFC] Perl6 Operator List, Take 5
[EMAIL PROTECTED] (Damian Conway) writes: Forgive me but is this syntax really necessary. If you're going for user-definable operators, most of this syntax is entirely unnecessary. Take all the hairy stuff out of core and be done with it! This won't stop people arguing about it, though. :) -- Henry, I'm a Regent Master of the Ancient and Venerable House of Congregation. Being eccentrically dull is practically my job description. - Jonathan Jones
Re: [RFC] Perl6 Operator List, Take 5
[EMAIL PROTECTED] (Michael Lazzaro) writes: â  ⠦ ⠫ § ¿ â  â  Ω ø ¶ º â Â â ¤Â â ¥Â â ¹Â â ºÂ â ¡Â Ã Â Ë Â Â¬Â Ã Â Å Â â  ¡ ⠢ How does that translate to Perl 5? -- Almost any animal is capable learning a stimulus/response association, given enough repetition. Experimental observation suggests that this isn't true if double-clicking is involved. - Lionel, Malcolm Ray, asr.
Re: Vectorizing operators for Hashes
So is it usefull to make sence out of these :
hash ^[op] hash
hash ^[op] array
hash ^[op] scalar
array ^[op] array
array ^[op] scalar
Actually ,
I just want to understand , why so much accent is put on vectorizing
atomic operations with arrays . It seems that hashes are at least as
frequent . And automating operations on them may be just as usefull.
( my feeling is that the reason is not the same as in Matlab and such
.. Because it begin to look like Matlab .
)
with arrays we have to resolve the question :
what to do if a, b in a ^[op] b have different length
with hashes we will have this question
what to do if %a, %b in %a ^[op] %b have not the same set of keys
we can resolve it with properties on hashes.
%a is vector_intersect
%a is vector_unify
Now we have also this question :
what to do in %a ^[op] a
this again can be resolved by hash property :
%a is vector_maptoindex { return int rand }
I am not shure we need all this ( and in this form ) , but if
vectorizing array operations make operators so heavy , we have to
probably take a ride on it. I dont know. Or probably to go on that
path we should introduce tenzor operators . There was a discussion
about Sets .
how about having
a ???[op] b = [ array of a[x] op a[y] for all pairs x,y ]
this path have no end, but where to stop ??
arcadi.
Re: [RFC] Perl6 Operator List, Take 5
On Wednesday, October 30, 2002, at 03:07 PM, Damian Conway wrote: In creating my operator list I deliberated shied away from the unary and binary multimorphic forms. But I do see Graham's point and would favour retaining polymorphic unary C^ at least. Meaning that the list: + - force to numeric context - - force to numeric context, negate +^- force to numeric context, complement ~ - force to string context ~^- force to string context, complement simply becomes: ^ - complement (type-specific) + - force to numeric context - - force to numeric context, negate ~ - force to string context Correct? MikeL
Re: plaintive whine about 'for' syntax
On Wed, 30 Oct 2002, Graham Barr wrote: On Wed, Oct 30, 2002 at 01:57:00PM -0800, Dave Storrs wrote: *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. Ok, fair enough. --Dks
Re: [RFC] Perl6 Operator List, Take 5
Michael Lazzaro wrote: Meaning that the list: + - force to numeric context - - force to numeric context, negate +^- force to numeric context, complement ~ - force to string context ~^- force to string context, complement simply becomes: ^ - complement (type-specific) + - force to numeric context - - force to numeric context, negate ~ - force to string context Correct? that was what I was advocating, yes. Damian
Re: perl6 operator precedence table
On Fri, 25 Oct 2002, I wrote:
why not simply extend pattern-matching in a similar way to substr, making it
an L-value, so that one gets
$str ~ /[aeiou]+/ = vowels($)
or
$str ~ /\d/ {hyper-symbol}= (0) x {size-of-LHS-array};
On Thu, 24 Oct 2002, Larry Wall replied:
Problem with that...the replacement argument has to be lazy, and currently
the RHS of an assignment is actually evaluated before the left. You'd
really need something more like
$str =~ /\d/ = { 0 }
How about just
$str =~ /\d/ .= 0
or
$str =~ /\d/ .= { 1 + $_ . 7 }
in which using . (apply) would force a fetch of the LHS in advance of
evaluating the RHS. And for global-replace we could use the vector/hyper
notation:
$str =~ /\d/ [.=] 0
However, I think readability suffers without a hint on the front what
you're trying to do.
We don't in general have a let on the front of assignment statements; why
should this type of assignment be any different? (Do we want a let keyword?
Personally I don't think so, but what do others think?)
-Martin
--
How to build a Caspian Sea oil pipeline - step one: get elected president...
Re: Vectorizing operators for Hashes
hash ^[op] hash ... array ^[op] scalar ie, generally: term ^[op] term what to do if a, b in a ^[op] b have different length what to do if %a, %b in %a ^[op] %b have not the same set of keys what to do in %a ^[op] a [what to do] resolved by hash property : I'd expect adverbs rather than adjectives for these sorts of issues, ie ':' modifiers of vectorization rather than use of variable/value properties. a ???[op] b = [ array of a[x] op a[y] for all pairs x,y ] this path have no end, but where to stop ?? b4p6J! ; (http://jsoftware.com/) Seriously, I also think it's worth seeing where this goes. As noted above, I'd expect use of adverbs to allow modification of hyperactivity: %a ^[op] %b : union Of course, this suffers the obtw problem. An alternative might be: %a ^:union[op] %b I can definitely see scope for wanting separate adverbs to influence how vectorization works on the lhs and rhs. Perhaps %a :foo[op]:bar %b where I'm assuming :[op] instead of ^[op] as the base syntax for vectorization. -- ralph
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: Vectorizing operators for Hashes
fc == [EMAIL PROTECTED] writes:
fc So is it usefull to make sence out of these :
fc hash ^[op] hash
fc hash ^[op] array
fc hash ^[op] scalar
fc array ^[op] array
fc array ^[op] scalar
well, you can't mung the keys to a hash, just the values. so why not
just use the values method as an [lr]value? this works already in perl5.
%hash.values [+]= 10 ;
%hash1.values [+]= %hash2.values ;
now that may fail as the order of the values would be different so use a
slice:
%hash1.values [+]= %hash2{%hash1.keys} ;
uri
--
Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com
- Stem and Perl Development, Systems Architecture, Design and Coding
Search or Offer Perl Jobs http://jobs.perl.org
Re: [RFC] Perl6 Operator List, Take 5
Larry elucidated: In general, for any type, how do you write [$min .. $max - $step : $step] when you don't even necessarily have subtraction defined? We don't know how to do z - 1 in Perl 5, for instance. Okay. I buy that. 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: worth adding collections to the core language?
Larry wrote:
The set features are a side effect of junctions, just as they're a side
effect of hashes. An any junction might well be implemented underneath
as a hash without values.
Yep.
Possibly we might even extend the notion of hash to any junk.
%hash = 1 | 2 | 3;
So you're suggestion that a normal hash is a junction of pairs???
Or that assigning a junction to a hash takes every state of the junction
and creates an entry for it whose value is true???
Either way I worry about this notion, because of the subtle
differences between:
%hash = map {$^x=1} (1,2,3);
%hash = any(1,2,3);
%hash = all(1,2,3);
%hash = one(1,2,3);
%hash = none(1,2,3)
I'd really rather not see junctions being the only scalar type that can be
marked with C%.
Unless, of course, we're deliberately *trying* to install nasty
inconsistencies for Simon to discover! ;-)
Then it's clearer that something junctional is going on when you say:
if $val ~~ %hash
I could see % becoming the sigil of choice for junks just for the
documentational value.
Curiously, the reduction of the documentational value of C% always
meaning hash is exactly why I *wouldn't* like to see it!
Damian
Re: Perl6 Operator List, Damian's take
Larry wrote:
That's almost a reduce. Pity you have to include a variable.
But since rvalues are illegal on the left side of an assignment, we
*could* go as far as to say that
0 [+=] b; # sum
1 [*=] b; # product
'' [~=] b; # cat
dwim into reduce operators rather than being illegal.
ETOOCLEVERBYHALF, IMHO. ;-)
I'd much rather see these common reductions be predefined Csum,
Cproduct, and Ccat methods of Array, and the more obscure
and bizarre reductions be explicitly marked with a Creduce:
my $countersequence = reduce {$^x-$^y}, b
Damian
Re: Perl6 Operator List (REMAINING ISSUES)
-- On Wed, 30 Oct 2002 16:37:09 Michael Lazzaro wrote: OK, by my count -- after editing to reflect Larry's notes -- only a few issues remain before the ops list can be completed. 1) Need a definitive syntax for hypers, ^[op] and +op; have been most seriously proposed -- something that keeps a bracketed syntax, but solves ambiguity issues. Maybe this is a bit radical (but hey, I'm not ashamed) but why not do what Larry proposed way back in Apoc. 1, namely, grabbing from iterators. Angel Faus already made a proposal for grabbing them for a qw() variant. I'd prefer stealing them for hyperop meself. I love hyperops (vector ops, if you prefer), can't easily type +hyperop;, and ^[hyperop] leaves a bad taste in my mouth. Maybe we could give fuel to Cozen's fire by totally dropping consistency, and generalize hypers to some quote like variant allowing you to define your own delimiters. Hey! then maybe hyper is spelled map . . . -Erik -- On Wed, 30 Oct 2002 16:37:09 Michael Lazzaro wrote: OK, by my count -- after editing to reflect Larry's notes -- only a few issues remain before the ops list can be completed. 1) Need a definitive syntax for hypers, ^[op] and +op; have been most seriously proposed -- something that keeps a bracketed syntax, but solves ambiguity issues. 2) Possible inclusion of unary prefix ^, meaning complement. (Assuming doesn't conflict with (1)) 3) Possible inclusion of like/unlike or similar as synonyms for ~~ !~. Which we don't have to decide now. All other op issues, by my count, revolve around the meanings of specific hyperop constructs. There is one, overriding question with the hyperops, which is the precise relation between an op, an assignment op, and their (three!) hyperop equivs: A op B A op= B A ^[op] B A ^[op=] B A ^[op]= B If we can formalize the precise relationship between the three hypers in the presence of scalar and list (and hash?) values for A and B, I believe we can answer nearly all the hyperop questions definitively. For example: a ^[op] b # array v array $a ^[op] b # scalar v array a ^[op] $b # array v scalar $a ^[op] $b # scalar v scalar a ^[op=] b # array v array $a ^[op=] b # scalar v array a ^[op=] $b # array v scalar $a ^[op=] $b # scalar v scalar a ^[op]= b # array v array $a ^[op]= b # scalar v array a ^[op]= $b # array v scalar $a ^[op]= $b # scalar v scalar Some of these are nonsensical, some of them aren't. So which are which, and can someone demonstrate that the rule holds true for ALL hyperoperators, as opposed to just MOST? ;-) MikeL Get 25MB of email storage with Lycos Mail Plus! Sign up today -- http://www.mail.lycos.com/brandPage.shtml?pageId=plus
Re: perl6 operator precedence table
Date: Thu, 31 Oct 2002 13:02:44 +1300 (NZDT) From: Martin D Kealey [EMAIL PROTECTED] We don't in general have a let on the front of assignment statements; why should this type of assignment be any different? (Do we want a let keyword? Personally I don't think so, but what do others think?) I think people want it. I mean, nobody complained when it was added to the language in A5 :) Luke
Re: [RFC] Perl6 Operator List, Take 5
On 30/10/02 13:41 -0800, David Wheeler wrote: On Wednesday, October 30, 2002, at 01:35 PM, Graham Barr wrote: On Wed, Oct 30, 2002 at 01:25:44PM -0800, Austin Hastings wrote: --- Larry Wall [EMAIL PROTECTED] wrote: Do these French quotes come through? @a «+» @b Odd, I see them in this message. But In the message from Larry I see ?'s And I didn't see them in Austin's message, but I see them in yours. Your mailer did the right thing, it looks like. And I see white question marks over black diamonds on a white background. Of course the OS X termcap is imfamous. Cheers, Brian
Re: Vectorizing operators for Hashes
On Wed, 30 Oct 2002, Me wrote: %a ^:union[op] %b %a :foo[op]:bar %b I think that any operators over 10 characters should be banished, and replaced with functions. ~ John Williams
