Re: Perl 6 and Set Theory
Luke Palmer wrote about:
=head1 Perl 6 and Set Theory
This document will introduce a new way of thinking about some Perl 6
constructs. In addition, it proposes some minor changes that would
help this way of thinking be more consistent. These changes may make
Perl 6 a better language in general, as a side effect.
Even in absence of an explicit "set" type, Perl 6 is quite proficient
in set theory. There are two types of sets it knows about: finite and
infinite. The former we call "junctions," while "classes" make up
infinite sets.
Theoretically at least, junctions can be non-finite too:
$pos = any(1...);
$big = any(1e6...);
=head2 Junctions
Junctions are a transparent mechanism for dealing with finite sets.
They indeed hold a discrete set of objects, but operations on the
junction are automatically delegated to operations on its members.
The two types of junctions, disjunctive (C) and conjunctive
(C) just determine how the junction is evaluated in boolean
context.
There are actually four types of junction:
conjunction: all(@elements)
disjunction: any(@elements)
abjunction:one(@elements)
injunction: none(@elements)
The expressions:
1 | 2 | 3
any(1, 2, 3)
1 & 2 & 3
all(1, 2, 3)
1 ^ 2 ^ 3
one(1, 2, 3)
none(1, 2, 3)
represent the set:
{ 1, 2, 3 }
Which we will call N. Performing some
unary...
operation I on them constructs and returns the set:
{ z(x): x ∈ N }
If, for example, this operation is C<{ $^x + 2 }>, we have:
{ x + 2: x ∈ N }
or
{ 3, 4, 5 }
If that was a comparison operation, say C<{ $^x > 2 }>, the resultant
set would be:
{ undef, undef, 1 }
Err, no. The result is:
{ 1 }
Comparison of a junction returns those states for which the comparison is true.
Furthermore, the resulting junction has a truth property assigned, according to
the truth of the comparison. Furtherurthermore, the type of the rsulting junction
is the same as the type of the junctive operand.
For example:
all(1..4) > 2 > all(3,3) but false
all(1..4) > 0 > all(1,2,3,4) but true
any(1..4) > 2 > any(3,4) but true
any(1..4) > 5 > any() but false
one(1..4) > 2 > one(3,4) but false
one(1..4) > 3 > one(4) but true
none(1..4) > 2 > none(3,4) but false
none(1..4) > 5 > none() but true
Evaluating this in boolean context should be true if the junction was
conjunctive, and false if it was disjunctive. So, for a junction J,
boolean context evaluation is defined as follows:
{ ∃x: x ∈ J ∧ ?x, disjunctive
?J ≡ {
{ ∀x: x ∈ J ⇒ ?x, conjunctive
Pre-empted, of course, by the above truth/falsehood properties.
In general, the logic is:
{ ∃x: x ∈ J ∧ ?x,disjunctive
{
{ ∀x: x ∈ J ⇒ ?x,conjunctive
?J ≡ {
{ ∃x: x ∈ J ∧ ?x ∧ ∀y: y ∈ J ⇒ x=y ∨ !y, abjunctive
{
{ ∀x: x ∈ J ⇒ !x,injunctive
That is, the "type" of junction just determines whether the quantifier
is existential or universal.
or exclusive or counterexistential.
There is one behavior of junctions, however, that doesn't work with
this definition: If a boolean operation is applied in non-boolean
context to a junction, it will return a junction of only the values
for which the condition evaluated true. But with a few minor changes,
this can be achieved:
• Junctions discard Cs on-sight (i.e. C can never be
a member of a junction).
• Comparison operators return C if they fail, and their
left-hand side "C" if they succeed.
• Comparison operators are right-associative.
Unfortunately, the last change clobbers the left-short-circuiting
behavior of comparison operators. A way to fix this would be to treat
a chain of comparison operators as a single n-ary operator. Other
methods for fixing this are welcome (and encouraged).
I'm not sure that any of the above semantic changes are required. All that is
needed is the define that logical operations on junctions return a junction of
the states of the leftmost junctive operand for which the operation was true.
And that the resultant junction be ascribed a C or C property
according to the overall truth/falsehood of the comparison.
Note that the definition of how junctions behave in itself allows
operators involving more than one junction to represent the outer
product of those junctions with respect to an operator. Consider two
sets, A = any(1,2,3), and B = all(4,5,6).
A + B = { x + B: x ∈ A }
= { { x + y: y ∈ B }: x ∈ A }
= { { 5, 6, 7 }, { 6, 7, 8 }, { 7, 8, 9 } }
Where each inner set is a conjunctive set, and the outer is a
disjunctive set.
No. At present, the proposal is that n arithmetic operation between
junctions produces a junction whose states are the distinct resul
Re: Perl 6 and Set Theory
> Date: Sun, 08 Dec 2002 19:10:30 +1100
> From: Damian Conway <[EMAIL PROTECTED]>
>
> There are actually four types of junction:
>
> conjunction: all(@elements)
> disjunction: any(@elements)
> abjunction:one(@elements)
> injunction: none(@elements)
Oh yeah...
> > represent the set:
> >
> > { 1, 2, 3 }
> >
> > Which we will call N. Performing some
>
> unary...
Sure. Any n-ary operation can be turned to unary with currying
anyway, right?
> > If that was a comparison operation, say C<{ $^x > 2 }>, the resultant
> > set would be:
> >
> > { undef, undef, 1 }
>
> Err, no. The result is:
>
> { 1 }
>
> Comparison of a junction returns those states for which the comparison is true.
> Furthermore, the resulting junction has a truth property assigned, according to
> the truth of the comparison. Furtherurthermore, the type of the rsulting junction
> is the same as the type of the junctive operand.
Yes, but I was trying to unify all kinds of operations. +'s junctive
semantics would be no different from >'s, except for the actual
function they performed.
And that would work with the "truth of the comparison" thing you just
said, except that 0 is false, so -2 + 2 would not be included in the
junction.
I guess a small distinction between comparison (or boolean, I suppose)
and non-comparison is okay.
> I'm not sure that any of the above semantic changes are required. All that is
> needed is the define that logical operations on junctions return a junction of
> the states of the leftmost junctive operand for which the operation was true.
> And that the resultant junction be ascribed a C or C property
> according to the overall truth/falsehood of the comparison.
Again, under the condition that operations can be classified logical
and non-logical. Ok.
> No. At present, the proposal is that n arithmetic operation between
> junctions produces a junction whose states are the distinct results
> of the operation applied pairwise to all possible combinations of
> states from each operand, and whose junctive type is the same as
> the left-most operand.
I can make a strong case against this behavior, at least:
(2 | 3) + (5 & 6) > 8
In English: Does either 2 or 3 (or both) have the property that when
you add it to _both_ 5 and 6 you achieve a result greater than 8. The
answer, of course is no. However,
(2 | 3) + (5 & 6) > 8
7 | 8 | 9 > 8 # True!!! Counterintuitive.
Another:
Same example, with operands swapped:
(5 & 6) + (2 | 3) > 8
7 & 8 & 9 > 8 # False!!!
Ok, not only can it provide counterintuitive results, but it makes
communitive operators not commute. That's Just Not Right.
And Another:
one(1, 40) + any(3, 4) > 42
In English: Does either 1 or 40 (but not both) have the property that
with you add it to either 3 or 4 (or both) you achieve a result
greater than the answer to life, the universe, and everything :)
This time, it's true. 40 has this property, but not 1. But,
one(1, 40) + any(3, 4) > 42
one(4, 5, 43, 44) > 42 # False!! Again, counterintuitive
> Presumably, under Luke's model:
>
> $C = foo($A, $B);
>
> would be the same as:
>
> $C = foo(1,4)&foo(1,5)&foo(1,6) |
>foo(2,4)&foo(2,5)&foo(2,6) |
>foo(3,4)&foo(3,5)&foo(3,6);
Right. Since junctions distribute (they'd better, lest I go
absolutely mad), that's equivalent to:
$C = (foo(1,4)|foo(2,4)|foo(3,4)) &
(foo(1,5)|foo(2,5)|foo(3,5)) &
(foo(1,6)|foo(2,6)|foo(3,6));
And whether you come up with this or the other depends on whether you
evaluate $A or $B first. Semantically, it doesn't matter either way.
> The semantics Luke suggests seem to be richer, but rely on the fixed
> precedence relationships between the various junctive types. I'd really
> like to (see someone else) explore how that expands to include abjunctions
> and injunctions, before I contemplated so fundamental a change in the
> semantics.
Um, what? The semantics I suggested have nothing to do with the
lexical representation of junctions at all. It's a purely logical
semantic. Unless I'm misunderstanding you...
I'll show you an example of abjunctions. Take my example from
earlier:
one(1, 40) + any(3, 4) > 42
This expands to:
one(any(1+3, 1+4), any(40+3, 40+4)) > 42
Which is true. If you happened to evaluate the any() first:
any(one(3+1, 3+40), one(4+1, 4+40)) > 42
Again, true. For the same reason too.
One thing I'd like to know is what none() means. Does it mean
"anything but" or "when tested against each argument, is false". I
assume the latter, for computational reasons. In which case I have
Yet Another example:
any(2, 3) + none(7) > 8
English: When seven is added to either 2 or 3 (or both), is the
result not greater than 8? The answer: no.
Under Quantum::Superpositions semantics:
any(2, 3) + none(7) > 8
any(9, 10) > 8# True! Wrong aga
Re: purge: opposite of grep
[EMAIL PROTECTED] (Damian Conway) writes: > Of course, as long as you can call C without explicitly loading > a module, it's merely a philosophical distinction as to whether > C is core or not. Well, no; it's an implementation distinction too. Non-core methods 1) don't mean anything special to the compiler 2) can be implemented in C, Perl, Parrot, or whatever else we like and 3) can be added or taken away without affecting the basic design of the language all of which means 4) we don't have to worry about them quite yet. Although the concept of having a data type called an array is core to the design of Perl 6, the precise clever methods those arrays respond to can be added organically later, or even customized by the end-user. Basically, I'm just saying that we don't have to put everything in at once. Let's have finish carving the statue before we decide what shade of vermillion to paint its toenails. -- >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: In defense of zero-indexed arrays.
On Fri, 06 Dec 2002 14:16:43 +, Brad Hughes wrote: > In any case, the choice of default base index is less important for Perl than > for other languages given how seldom arrays in Perl are accessed by index as > opposed to manipulated by push, pop, for $x (@array) loops and such. I slice a lot of lists, though, and expect the base index of a loop to have a certain resemblance to the base index of an array. -- c
Re: purge: opposite of grep
On Sun, Dec 08, 2002 at 11:28:24AM +1100, Damian Conway wrote: > We could certainly do that. But let's call it C. I usually just lurk here, but I just had to pipe in. :) I'm not sure the meaning of the name C would be obvious to someone who hadn't seen it before. I keep thinking C would be nice, or maybe C. Just a thought... - Ian.
Re: purge: opposite of grep
Damian Conway wrote:
sub part ($classifier, *@list) {
return @parts;
}
Given the original example
(@foo,@bar,@zap) := part [ /foo/, /bar/, /zap/ ] @source;
this binds the contents of @parts to (@foo,@bar,@zap)? The
array refs in @parts are not flattened though. Is it correct
to think of flattening context as a lexical flattening? i.e.
only terms written with @ are flattened and the types of
the terms can be ignored?
BTW, if part were declared as an array method, the syntax
becomes
@source.part [ /foo/, /bar/, /zap/ ]
or
part @source: [ /foo/, /bar/, /zap/ ]
Can part be a multi-method defined in the array class
so the original example syntax can be used? (I'd prefer
the code too because the switch statement is eliminated.)
sub convert_to_sub ($classifier is topic) is cached {
Very nice.
for @classifiers.kv -> $index, &test {
An array::kv method? Very useful for sparse arrays, but
is this preferred for all arrays? An explicit index counter
seems simpler in this case.
my @indices = map { defined .key()($nextval) ?? .value
:: () } %classifiers;
That map body looks like a syntax error, but it isn't. Can I add
extra syntax like
map { defined(.key.($nextval)) ?? .value :: () }
to emphasize the fact that .key is returning a code ref?
Last, but not least, the Hash case returns a junction (most
likely of a single value). Junctions don't collapse like
superpositions, so I'm wondering what really happens.
Can you describe the evaluation? I'm really interested in how
long the junction lasts (how quickly it turns into an integer
index), and what happens with a duplicate (ambiguous?) index.
Sorry for so many questions. The code you wrote was just a
really, really good example of many Perl 6 features coming
together.
[This is out of order; Damian wrote it in another message.]
> Everything doesn't. Everything shouldn't be. Just the really common,
> important stuff.
So CGI.pm is in?
I don't think "really common, important" is a good criteria for
being in the core. IMHO it should be "language defining, awkward or
impossible to implement as a module".
Perhaps the part method can be implemented as a mix-in module that
extends array without subclassing it? AUTOLOAD can do that now
for packages. Are classes sealed or will they use AUTOLOAD too?
- Ken
Re: IMCC and constants?
[EMAIL PROTECTED] wrote: .namespace WHILE_BLOCK You should make uniq namespace identifiers (WHILE_BLOCK_$w, $w++). The generated variables (WHILE_BLOCK::i) keep there life[1] after end of the namespace and might collide e.g. with ".local num i" in the next while block. [1] the varibale name and type is needed for register allocation. ... Here we can see that IMCC does not discover that I4 can be optimized away. Is that something I should be expecting in forthcoming IMCC releases? Constant propagation (and other optimizations) are planned, yes. I was thinking it might be nice to be able to do something like this in the .imc file: .local int N 100 # Constant implied by value after name This would help for the first occurance of N, but not in i.e.: i = N; j = i + i; BTW, thanks for producing imcc. Thanks forwarded to Melvin and Angel. Regards, -- Gregor leo
Re: purge: opposite of grep
On Saturday, December 7, 2002, at 10:47 PM, Damian Conway wrote: I keep thinking C would be nice, or maybe C. Just a thought... C is quite good. Though I still like C best. Ooh, I like C best. C is too easy to interpret as other things (partition? part with? part from? part of? partner? etc.). David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: purge: opposite of grep
David Wheeler wrote: > On Saturday, December 7, 2002, at 10:47 PM, Damian Conway wrote: > > > Ian Remmler decloaked and wrote: > > > > > I keep thinking C would be nice ... > > > > C is quite good. Though I still like C best. > > Ooh, I like C best. I dislike C cos it's a small typo away from C. Smylers
Re: purge: opposite of grep
On Sunday, December 8, 2002, at 10:20 AM, Smylers wrote: I dislike C cos it's a small typo away from C. Yes, but I would expect to be a compile-time error, since the signatures are different. The same can't be said for r?index. David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: purge: opposite of grep
Ken Fox asked:
sub part ($classifier, *@list) {
return @parts;
}
Given the original example
(@foo,@bar,@zap) := part [ /foo/, /bar/, /zap/ ] @source;
this binds the contents of @parts to (@foo,@bar,@zap)?
Yes.
The array refs in @parts are not flattened though.
Correct. Each array ref is bound to the corresponding array name.
>
Is it correct
to think of flattening context as a lexical flattening? i.e.
only terms written with @ are flattened and the types of
the terms can be ignored?
I'm not sure I understand this question.
BTW, if part were declared as an array method, the syntax
becomes
@source.part [ /foo/, /bar/, /zap/ ]
Nearly. The parens are not optional on this form of method call, I believe.
So that would be:
@source.part([ /foo/, /bar/, /zap/ ]);
or
part @source: [ /foo/, /bar/, /zap/ ]
Yes.
Can part be a multi-method defined in the array class
Multimethods don't belong to any particular class.
Does it *need* to be a method or multimethod???
for @classifiers.kv -> $index, &test {
An array::kv method? Very useful for sparse arrays, but
is this preferred for all arrays? An explicit index counter
seems simpler in this case.
Depends on your definition of simpler, I guess. Depending on what you mean by
"explicit index counter", that would have to be:
for [EMAIL PROTECTED] ¦ @classifiers -> $index, &test {
...
}
Or (heaven forefend!):
loop (my $index=0; $index<@classifiers; $index++) {
my &test := @classifiers[$index];
...
}
I really think an C method nicely meets the very common need of
iterating the indices and values of an array in parallel, with a minimum
of syntax and a maximum of maintainability.
my @indices = map { defined .key()($nextval) ?? .value
:: () } %classifiers;
That map body looks like a syntax error, but it isn't.
> Can I add extra syntax like
map { defined(.key.($nextval)) ?? .value :: () }
to emphasize the fact that .key is returning a code ref?
Yes, indeed.
Last, but not least, the Hash case returns a junction (most
likely of a single value). Junctions don't collapse like
superpositions, so I'm wondering what really happens.
Can you describe the evaluation?
Sure. Suppose that the classifier closure returns the junction C.
Then, within C, the C<$index> variable stores that junction (i.e. junctions
survive both a copy-on-return and an assignment). The next statement is:
push @parts[$index], $nextval;
The use of a junction as an index causes the array look-up to return a junction
of aliases to the array elements selected by the various states of the index.
So C<@parts[$index]> is a disjunction of a single alias (i.e. to C<@parts[1]>).
Pushing the next value onto that alias causes it to autovivify as an array ref
(if necessary), and then push onto that nested array.
Suppose instead that the classifier closure returns the junction C.
Then, within C, the C<$index> variable stores that junction, and its use
as an index causes the array look-up to return a junction
of aliases to the array elements selected by the two states of the index.
So C<@parts[$index]> is, in this second case, a disjunction of two aliases
(i.e. to C<@parts[0]> and C<@parts[1]>). Pushing the next value onto that
disjunctive alias causes it to autovivify both elements as array refs
(if necessary), and then -- in parallel -- push the value onto each nested array.
I'm really interested in how
long the junction lasts (how quickly it turns into an integer
index),
It never turns into an integer index. Using a junction as an index is the
same as passing it to the C method, which causes the
call to the method to be distributed over each state in the junction. So, just
as:
foo(1|2|3)
is the same as:
foo(1) | foo(2) | foo(3)
so:
@array[1|2|3]
is the same as:
@array[1] | @array[2] | @array[3]
And:
@array[1|2|3] = "str";
is the same as:
(@array[1] | @array[2] | @array[3]) = "str"
which the same as:
(@array[1] = "str") | (@array[2] = "str") | (@array[3]) = "str")
and what happens with a duplicate (ambiguous?) index.
Can't happen. As Luke has expounded, junctions are a form of set,
and have no duplicate states.
Perhaps the part method can be implemented as a mix-in module that
extends array without subclassing it?
And I'm suggesting that Cing is such sweet sorrow that everyone
will want to do it all the time. Or at least often enough that dragging
it in from a module with rapidly become a PITA. Just as it in Perl 5
to use C or C.
Manipulating a core data type in commonly useful ways ought to be via
core operations (or, at worst, operations that are invisibly non-core),
so that JAPHs are encouraged to code what they mean explicitly:
$sum = reduce {$^a+$^b} @nums;
$max = max @nums;
rather than emergently:
my ($max, $sum) = (-Inf, -Inf);
for @nums {
$max = $_ if $max < $_;
$sum += $_;
}
AUTOLOAD can do that now
for packages
Re: purge: opposite of grep
David Wheeler wrote: Ooh, I like C best. C is too easy to interpret as other things (partition? part with? part from? part of? partner? etc.). You know, that's *exactly* why I like C better. ;-) Damian
Re: purge: opposite of grep
Damian Conway wrote:
Ken Fox asked:
Is it correct
to think of flattening context as a lexical flattening? i.e.
only terms written with @ are flattened and the types of
the terms can be ignored?
I'm not sure I understand this question.
Sometimes array references behave as arrays, e.g.
push $array, 1
In flattening context array refs don't flatten, only arrays.
I'm not even sure that only arrays flatten either -- it might
be anything that begins with @. e.g.
my Point @p;
($x, $y) := @p;
If the flattening rule is "only @ symbols flatten" then it
would be lexical flattening -- we only have to look at the
text. (I'm using lexical in the same sense as lexical
variable uses it.)
Multimethods don't belong to any particular class.
Does it *need* to be a method or multimethod???
If C is not a method or multimethod, then it acts
like a reserved word or built-in, like C or C.
IMHO that's name space pollution.
I know multi-methods don't "belong" to a class. It seems
useful to develop standards on where the implementation
is found though. I would expect to find C as an
auto-loaded multimethod in "perl6/6.0/auto/array/part.al"
It would actually be nice if all the C, C,
etc. functions became methods, e.g.
push @array: 1;
Depends on your definition of simpler, I guess.
I don't see anything particularly complex about this:
my $index = 0;
for @classifiers {
return $index if $_.($nextval);
++$index
}
That's understandable and it should produce simple bytecode.
If @classifiers is sparse or non-zero-based, then the .kv
method might be better.
I really think an C method nicely meets the very common need of
iterating the indices and values of an array in parallel, with a minimum
of syntax and a maximum of maintainability.
Yes, I agree, but it needs to construct a stream generator
which isn't particularly efficient. I was surprised to see it
in a place where the generality and elegance isn't needed.
Thanks for the explanation of the junction. I'm not sure
whether I'm more excited by the possibility to write code
using junctions or more terrified by the certainty of
debugging that code... ;)
And I'm suggesting that Cing is such sweet sorrow that everyone
will want to do it all the time. Or at least often enough that dragging
it in from a module with rapidly become a PITA. Just as it in Perl 5
to use C or C.
How about formalizing global namespace pollution with something
like the Usenet news group formation process? Ship Perl 6 with a
very small number of global symbols and let it grow naturally.
- Ken
[perl #18967] [PATCH] Configure enables -g even if request is otherwise
# New Ticket Created by mrnobo1024
# Please include the string: [perl #18967]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=18967 >
If -g is not requested, Configure says (none requested) but puts it in the
compiler flags anyway.
__
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
-- attachment 1 --
url: http://rt.perl.org/rt2/attach/44531/35166/0653cf/debug.patch
--- parrot/config/init/debug.pl.origWed Sep 4 17:15:50 2002
+++ parrot/config/init/debug.pl Tue Dec 3 16:56:30 2002
@@ -9,22 +9,23 @@
@args=();
sub runstep {
- if (! Configure::Data->get('debugging')) {
+ if (Configure::Data->get('debugging')) {
+my($ccflags, $linkflags, $ldflags) =
+Configure::Data->get(qw(ccflags linkflags ldflags));
+my($cc_debug, $link_debug, $ld_debug) =
+Configure::Data->get(qw(cc_debug link_debug ld_debug));
+$ccflags .= " $cc_debug";
+$linkflags .= " $link_debug";
+$ldflags .= " $ld_debug";
+
+Configure::Data->set(
+ ccflags => $ccflags,
+ linkflags => $linkflags,
+ ldflags => $ldflags,
+);
+ } else {
print "(none requested) ";
}
- my($ccflags, $linkflags, $ldflags) =
- Configure::Data->get(qw(ccflags linkflags ldflags));
- my($cc_debug, $link_debug, $ld_debug) =
- Configure::Data->get(qw(cc_debug link_debug ld_debug));
- $ccflags .= " $cc_debug";
- $linkflags .= " $link_debug";
- $ldflags .= " $ld_debug";
-
- Configure::Data->set(
- ccflags => $ccflags,
- linkflags => $linkflags,
- ldflags => $ldflags,
- );
}
1;
Tinderbox summary
I've gotten tired of endlessly clicking on tinderbox links to try to figure out what's generally going wrong, so I made my computer do it for me. Yes, I should have just made a script that runs on the tinderbox machine or something instead of parsing Data::Dumper output, but I didn't want to bother figuring out where to plug things in. You can see the results here: http://foxglove.dnsalias.org/parrot/ In brief: glastig, drinky-drinky, and one of the frivolous configurations (?) need to have their checkouts blown away, or just have their parrot/languages/CVS/Entries file edited to delete the D/brainfuck line. Tru64 unix seems unhappy with multiarray tests 2+3. TD-Seville is exploding while trying to compile an alignment test program. And a few other machines have a few other scattered failures. I haven't been following things that well; are any of the remaining ones known problems? (eg do some of these still need the registers to be scanned during DOD?)
Re: Tinderbox summary
At 19:55 on 12/08/2002 PST, Steve Fink <[EMAIL PROTECTED]> wrote: > You can see the results here: http://foxglove.dnsalias.org/parrot/ I'm getting a 404 on that. --Josh
right-to-left pipelines
[snipped]
> so it's easy to build up more complex right-to-left pipelines, like:
>
> (@foo, @bar) :=
> part [/foo/, /bar/],
> sort { $^b <=> $^a }
> grep { $_ > 0 }
> @data;
>
>
I would like perl6 to support left-to-right part/sort/grep pipelines.
Left to right syntax is generally good because it facilitates the flow
of reading.
For these pipelines, the current right to left syntax is due to the emphasis
on the operation over the data operated on, so the operator appears
first. Nevertheless with a long pipeline, data is best factored out in a
variable so having it first is not an impediment.
Tentative syntax:
... is an left-associative operator that has the same precedence as .
argexpr...listop indirop
would be equivalent to
listop indirop argexpr
example:
@data = [ very_long_data_expression ]
(@foo, @bar) := @data...grep { $_ > 0 }...sort { $^b <=> $^a }...part [/foo/, /bar/];
Also, I am not necessarily advocating that operators like :=
could be flipped to become := with flipped operands:
@data...grep { $_ > 0 }...sort { $^b <=> $^a }...part [/foo/, /bar/] =: (@foo,
@bar)
I am just advocating to examine the idea. :)
I certainly see an imediate problem with the current conventions:
=~ and ~= are two different beasts, not one beast and its flipped version.
__
stef
Re: right-to-left pipelines
> Date: Mon, 9 Dec 2002 06:00:40 +0100
> From: =?iso-8859-1?Q?St=E9phane?= Payrard <[EMAIL PROTECTED]>
> Damian:
> > so it's easy to build up more complex right-to-left pipelines, like:
> >
> > (@foo, @bar) :=
> > part [/foo/, /bar/],
> > sort { $^b <=> $^a }
> > grep { $_ > 0 }
> > @data;
> >
> >
>
> I would like perl6 to support left-to-right part/sort/grep pipelines.
> Left to right syntax is generally good because it facilitates the flow
> of reading.
>
> For these pipelines, the current right to left syntax is due to the emphasis
> on the operation over the data operated on, so the operator appears
> first. Nevertheless with a long pipeline, data is best factored out in a
> variable so having it first is not an impediment.
[snip]
I was just playing with Mathematica and thinking this very same thing.
Mathematica has an operator // that applies arguments on the left to
the function on the right. I was just thinking how good that was for
clarity. To do some awful computation, and get a numeric result, you
can write:
N[awful computation]
Or:
awful computation // N
I was instantly reminded of TMTOWTDI, in a good way. Perhaps Perl
could adopt a similar mechanism? The operator in question should have
very low precedence. >> is available, I think, since bitops are
prefixed with . or whatever.
$0{statement}{expression}{additive_expression}[0] >> print;
That's rather nicer, IMHO, than:
print($0{statement}{expression}{attitive_expression}[0]);
You could even give a closure:
$0{...} >> { print $^v, "\n" }
Not that anyone would. The situation is analogous to that of:
die "Can't do it" unless something;
versus
something or die "Can't do it";
It allows for moving the important stuff out to the left (Depending on
what you consider important).
@a >> grep { $_ > 0 } >> sort >> { print $^v, "\n"}
Aha! That's when you use the closure. Unix pipelines are so nice to
script with, why shouldn't Perl steal them? :)
> Also, I am not necessarily advocating that operators like :=
> could be flipped to become := with flipped operands:
>
> @data...grep { $_ > 0 }...sort { $^b <=> $^a }...part [/foo/, /bar/] =: (@foo,
>@bar)
>
> I am just advocating to examine the idea. :)
> I certainly see an imediate problem with the current conventions:
> =~ and ~= are two different beasts, not one beast and its flipped version.
Yeah... I don't think that would work so well. There's just too many
operators that have meanings both ways.
Luke
Re: Tinderbox summary
On Dec-09, Josh Wilmes wrote: > > At 19:55 on 12/08/2002 PST, Steve Fink <[EMAIL PROTECTED]> wrote: > > > You can see the results here: http://foxglove.dnsalias.org/parrot/ > > I'm getting a 404 on that. Well, of course you would! Don't you know anything about the web? You should have figured out that I would probably pick the wrong name initially (/perl6), test it that way, then change it at the last minute before I sent out the email. And from there, it's not the slightest bit difficult to guess that I would forget to restart Apache, and realize that I expected you to break into my machine and restart it for me. Sheesh, some people expect me to do all their thinking for them. I meant to say: thanks, I messed up. It should be fixed now. Oops. But make sure you use the trailing slash.
Re: Fw: right-to-left pipelines
Note: this is back on-list. > From: "Me" <[EMAIL PROTECTED]> > Date: Mon, 9 Dec 2002 01:27:55 -0600 > > [regarding -> as a left-to-right pipe-like operator] > > Please do. As in, please point out on list that > '->' is already established as a left-to-right > flow/assignment operator so why not consider > extending/modifying it to be more general? ;> I would, except for '->' isn't (in my mind) "a left-to-right flow/assignment operator." It's a unary operator, synonymous with "sub" without parens required around the argument list. Luke
