Re: Junction Values
Hmm. On rereading my last message, I feel that it comes across as angry, and critical of this entire discussion or perhaps of particular participants. That was certainly not my intent and I apologize if that's how it appeared. I genuinely respect the contributions of every person on this list, and even when (as now) I strenuously disagree with the ideas expressed, I know that those contributions are sincere and offered with the best interests of Perl at heart. I still stand by every point I made in that last message, but I'm sorry that I let my frustrations leak into the discussion. Damian
Re: Junction Values
On Fri, Feb 18, 2005 at 11:31:54PM -0800, Brent 'Dax' Royal-Gordon wrote: Junctions are intended to ultimately be used in boolean tests. That's why the values of the junction have an any/all/one/none relationship. The proper data structure here is an array. (Actually, ironically enough, it's probably a set, not an array.) It's one set for any()/all()/one() and two sets for none(). Of course, if something (eg. functions) cannot be tested for equality, then we'll have to assume them to be unique from each other anyway, in which case junctions do act as arrays. [1] Note, however, that this needs to be done carefully. For example, while it doesn't really make sense for the string arguments of a call to Cprint to be junctions, the object argument is another matter entirely: #!/usr/bin/perl6 # naive tee $OUT=$OUT open( $_) for @ARGS; print or die Can't write to $!.filename: $! for *$IN;# Or however it's done this week I think it's an unary = this week, according to S04: print for =*$IN; Thanks, /Autrijus/ pgpK2a19S3Fk6.pgp Description: PGP signature
Re: Junction Values
Brent 'Dax' Royal-Gordon wrote: Rod Adams [EMAIL PROTECTED] wrote: The caller is not in a position to know if the callee is internally structured in such a way that passing in a raw junction makes sense. Sure they are. It's called reading the documentation. If it doesn't say it can handle junctions, it probably can't. I don't want to have to stop in the middle of a hundred-line function to think, Does Store::Market.get act sanely when I give it a junction? Do I need to explode it manually, or will it handle the junction nicely on its own? You call functions where you don't know what data types they are expecting? That's... surprising. Even in a loosely typed world like Perl, knowing what a sub or method is expecting to be fed seems like a good idea to me. I see checking for accepting junctions as input as being on the same level as Does it want a list or an arrayref here?. When I'm writing my own insanely large functions, I'm constantly hitting the docs to see the nuances about the method calls I'm not already intimately familiar with. And if I'm going to attempt to use a function in a new way (like feeding it a Junction), I recheck the docs to make sure I'm not setting myself up for trouble down the road. Your mileage may vary. -- Rod Adams. (PS - This should not be construed to be an attack on you or your programming style. It is not. Though I've never seen you in action, I have every reason to believe you are a fully competent developer. It is simply a response to your statement above, explaining why I thought the attitude expressed there represented a weak argument.)
='s LHS
Is ='s LHS still automatically quoted? What are the rules? Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: Junction Values
Damian Conway wrote:
Rod Adams wrote:
All I want now is for autothreading to be explicit.
It already *is*.
The only way that:
is_prime($x)
can ever autothread is if $x holds a junction. But that can now only
happen if there's an explicit Cuse junctions in scope where $x was
assigned to (or the explicit use of some other module that also
activates Cuse junctions). So $x having a junction must be a known
possibility at that point.
Of course, literal junctions *will* autothread in all circumstances:
is_prime(any(6,7,8))
is_prime(6|7|8)
I had not caught the difference between:
use junctions;
$x = 6|7|8;
if is_prime($x) {...}
and
if is_prime(6|7|8) {...}
before. Is this new, or yet another important detail I missed along the
way? Or is this a side effect of not being able to store a Junction, and
can go away if C use Junctions is turned on?
But they're both explicit too: you're explicitly using junction
constructors, so the autothreading can hardly come as a surprise.
*If* we are guaranteed than an explicitly created junctions will always
autothread, I'll agree with this.
I will, however, question if this is optimal. Compare two simple cases:
C $x == any(4,5,6) and C $x all(4,5,6) . Both of them are prime
candidates to some optimizations, but the optimizations are likely
rather different. If we pass the junction into the operator, then it can
perform some custom tailored code, to make things much more efficient,
instead of relying on a more generalized junction optimizer to handle
things.
What this also means is that if you wish to pass an anonymous junction,
you can't. You have to do something like:
{
use junctions;
some_func(my $x = any(4|5|6));
}
Which just seems silly.
And if:
is_prime($x)
does happen to autothread when you weren't expecting it to, then one
of two things will happen. Either the subroutine will be 'pure' in
which case there's no problem in autothreading it; or else the
subroutine will have side effects, in which case you'll get an
explicit warning when the autothreading occurs.
I addressed earlier concept of how does perl know when there are side
effects, particularly with the execution path can weave to parts written
in pure-parrot. In particular, if the Patrick responded by implying
that there was no such side effect protection. see:
http://www.nntp.perl.org/group/perl.perl6.language/19210 (my post)
http://www.nntp.perl.org/group/perl.perl6.language/19212 (Patrick's
response)
I see your statements on the subject, and Patrick's to be at odds. But
then again, it might be that I've misread something again, though I'm
doing my best to avoid it now.
I request some clarification on this. If nothing else, to make sure you
and Patrick have the same understanding of what's happening.
This problem goes away completely with explicit autothreading. perl
would no longer be making assumptions about what to autothread, and what
to carp over.
Personally, I think it's completely fascist to require a Cuse
junctions pragma in order for junctions to even be stored in
variables. It's as bizarre as requiring Cuse strings or Cuse
references or Cuse undef or Cuse infinities would be. Yes, it
*is* possible to get unexpected behaviour from passing a junction
where it isn't expected, but it's already possible to get unexpected
behaviour by passing a string or an undef or a reference or an object
where it isn't expected. Junctions are nothing new in that respect.
I had it in my head that if I were to get my »Junction« explicit
threading idea, I was going to follow up by saying the block against
storing junctions was a case of diminishing returns at that point, and
should probably go away. I appreciate the stop-gap measure that it was,
but I'd prefer to solve the real problem at hand.
Ironically, by using the Awesome Power of Junctions:
I hope I never gave the impression that I felt Junctions were not
powerful... That was not the case. If anything, I was arguing that they
were *too* powerful... But in the end, I realized it's just the implicit
autothreading I didn't like.
Look, I do understand the arguments in the other direction. I've
understood them for the past five years that I've been developing the
concept of superpositional data-types. I've thought them through
numerous times myself, and in the end: I just don't buy them.
The whole point of junctions is to make the threading of operations on
datasets both automatic and implicit; to make it Do The Right Thing
without the hassles of explicit threading. If you don't want that,
that's fine: just don't use junctions. Use arrays and hyperoperators
instead. And we'll happily give you a Cno junctions pragma so you
can be emphatic about not wanting them.
I can certainly understand the hassles of explicit threading if one is
thinking:
$y = func(any(3|4|5));
has to be explicitly written as:
$y = any(any(3|4|5).values().map(func($_)));
or some such, but is it
Re: ='s LHS
On Sat, Feb 19, 2005 at 09:10:05PM +0100, Juerd wrote: Is ='s LHS still automatically quoted? What are the rules? S02 says that = still autoquotes any bare identifier to its immediate left, even keywords and macros. Pm
Re: ='s LHS
Patrick R. Michaud skribis 2005-02-19 14:53 (-0600): On Sat, Feb 19, 2005 at 09:10:05PM +0100, Juerd wrote: Is ='s LHS still automatically quoted? What are the rules? S02 says that = still autoquotes any bare identifier to its immediate left, even keywords and macros. Thanks - I wonder how I managed to read that without absorbing the information. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: Junction Values
Damian Conway wrote: Hmm. On rereading my last message, I feel that it comes across as angry, and critical of this entire discussion or perhaps of particular participants. That was certainly not my intent and I apologize if that's how it appeared. I genuinely respect the contributions of every person on this list, and even when (as now) I strenuously disagree with the ideas expressed, I know that those contributions are sincere and offered with the best interests of Perl at heart. I still stand by every point I made in that last message, but I'm sorry that I let my frustrations leak into the discussion. Damian Well, I for one, never took any offense to any of the responses sent my way. And I appreciate the patience it's likely taken to not just completely Warnock me. However, I also realize that I might have stepped on some toes of the course of this long discussion. Which was never my intention, and I'll apologize to any who feel I've slighted them in the process. I do believe everyone on this list shares the same goals of making Perl 6 the possible language that it can be. However, opinions will vary as to what that actually means. Being a group of people that can by and large be described as having a fairly large egos, these differences of opinion can become rather passionate. And passion leads to some pretty extreme responses. It certainly hasn't helped matters that the exact nature of my proposal has changed in some fairly drastic ways on a regular basis, as I came to a better understanding of what Junctions were, and how they were being implemented. I apologize for any confusion this may have caused, but I do think the resulting discussions have shed some new insights on Junctions, Sets, what it means to have a sigil, why junctions can't just be another class, and several other topics. Poor Mr. Fowles is likely having nightmares figuring out how to summarize all of this. Positions I still stand by: - Sets belong in the language, and need more support. This can likely be done at the module level, but I'd like them better incorporated, preferably with their own sigil. However, I believe they can peacefully coexist with Junctions, and one concept does not need to crowd out the other. - Implicit autothreading is a Bad Thing, and should not happen. This is almost entirely due to the side effects such behavior can generate. To keep the power of junctions viable, explicit threading should be trivially easy, but it should be explicit, none the less. -- Rod Adams
Re: Junction Values
Rod Adams wrote:
I had not caught the difference between:
use junctions;
$x = 6|7|8;
if is_prime($x) {...}
and
if is_prime(6|7|8) {...}
There isn't one.
Is this new, or yet another important detail I missed along the way?
Or is this a side effect of not being able to store a Junction, and can go
away
if C use Junctions is turned on?
Yes, it's a side-effect of the new default prohibition on junction assignments
(though I'm still working hard to convince everyone that that prohibition
cripples junctions and that having to use junctions before you can assign a
basic Perl 6 scalar datatype to a variable is an abomination).
I will, however, question if this is optimal. Compare two simple cases:
C $x == any(4,5,6) and C $x all(4,5,6) . Both of them are prime
candidates to some optimizations, but the optimizations are likely rather
different.
If we pass the junction into the operator, then it can perform some custom
tailored code,
to make things much more efficient, instead of relying on a more
generalized junction
optimizer to handle things.
Sure. That's why we have the ability to specify subroutines where junctive
args are *not* autothreaded, by typing the corresponding parameter as taking a
junction:
multi sub infix:«==» (YourType $x, Junction $y) is symmetrical {...}
multi sub infix:«» (YourType $x, Junction $y) is symmetrical {...}
These two multisubs can optimize for junctive arguments to their hearts'
content.
I addressed earlier concept of how does perl know when there are side effects,
particularly with the execution path can weave to parts written in
pure-parrot.
In particular, if the Patrick responded by implying that there was no such
side
effect protection. see:
http://www.nntp.perl.org/group/perl.perl6.language/19210 (my post)
http://www.nntp.perl.org/group/perl.perl6.language/19212 (Patrick's response)
I don't see that Patrick's response implies that at all. In fact, I think his
statement that:
Well, the ultimate answer is that both Dan and Patrick (and others)
will negotiate the exact interface when we get to that point, and
that we don't seem to be too concerned about it at the moment.
(It could just be that we're both burying our heads in the sand
hoping it'll be magically solved by the other. :-)
However, in working out these examples I'm fairly comfortable that
it can be made to work at the Perl 6 compiler level if need be,
although it will probably be a lot more efficient if we can find a
way to do it within Parrot.
seems to confirm that detecting and reporting autothreaded side-effects is
entirely possible.
If nothing else, to make sure you and Patrick have the same understanding of what's happening.
I'm sure we will.
This problem goes away completely with explicit autothreading.
perl would no longer be making assumptions about what to autothread, and
what to carp over.
But that's the whole point of junctions! Namely that perl works it out for
you. If you don't want that to happen then don't use junctions (and don't
allow them to be used, by specifying Cno junctions).
If you want explicit threading (I refuse to call it autothreading; if it has
to be manually specified, it certainly isn't auto) then use arrays instead,
and thread your subroutines and operators over them using the explicit
hyperoperator notation (see example below).
But bowdlerizing the concept of junctions isn't the answer.
I'm no longer doing that.
Or at least, I'm no doing anything anywhere close to as extreme as some
of my other ideas over the last week or two. Which I can see perfectly
well, in retrospect, how you felt I was gutting the power away from
junctions, and how frustrating that must have been for you.
Thank-you for understanding that.
But I still don't like implicit autothreading, and likely never will. I
don't know how to explain it, but it just feels very wrong. It's down
there with using typeglobs to pass filehandles, which is thankfully
history.
I understand your qualms, even if you can't nail down the exactly reasons for
them.
However, I still disagree with them. I truly believe that junctions (including
their autothreading behaviour) ought to be core to Perl 6...and not ham-strung
in any way.
I appreciate that some people will not like the potential autothreading of:
if is_prime($x) {...} # Might possibly autothread
but I think it's sufficient to give those people:
# At the top of the program...
no junctions;
# and then...
if is_prime($x) {...} # Can't possibly autothread
As for explicit threading: hey, you've already got it. Just use an array
instead of a junction, and only allow explicit junctives. Either:
# At the top of the program...
no junctions 'assignment'; # Junctive constants okay
# and then...
if is_prime(any(@x)) {...} # Explicitly threaded
or, even more
Set sigils (was: Re: Junction Values)
On Sat, 19 Feb 2005 15:20:59 -0600, Rod Adams [EMAIL PROTECTED] wrote: Positions I still stand by: - Sets belong in the language, and need more support. This can likely be done at the module level, but I'd like them better incorporated, preferably with their own sigil. However, I believe they can peacefully coexist with Junctions, and one concept does not need to crowd out the other. Instead of primary sigils, what about secondary sigils on an array to mark it as an unordered set? @|foo = any @foo = all @^foo = one # can arrays be curried arguments? hmm @!foo = none After all, why should scalars get all the good secondary sigils? :) Ashley Winters
Lingering questions about Junctions.
Okay, Now that I've largely accepted junctions (except implicit autothreading, which is Bad.), I see some corners that need to be poked at in terms of how they fit into the language as a whole. All of these examples assume an appropriate level of use junctions; is in effect. - Can junctions be used as array/hash subscripts? In an rvalue context, this makes sense, in that you can simply return a junction of the deferences. But in an lvalue context, this gets dubious for everything except all() junctions. Consider: @x = 1..10; @x[any(4,3)] = 7; What does @x look like now? @x[all(4,3,2)] = 7; makes sense, as long as it means: @x[4,3,2] »=« 7; I don't want to even think about what: @x[none(1,2)] = 7; does. - Can you have non-scalar junctions? As the discussions surrounding C .. demonstrated, it's not that hard for someone to create a situation where a junction of lists might come into existence. But let's consider something a step beyond. %x = (a = 1, b = 2, c = 3) | (d = 4, e = 5, f = 6); @y = %x.keys; Does this explode, or does @y have something useful in it now? Before dismissing the concept completely, it's perfectly possible to create something much like a junctive hash via references: %x = (a = 1, b = 2, c = 3); %y = (d = 4, e = 5, f = 6); $z = one(\%x, \%y); @w = $z.keys; - What does it mean to sort a list of junctions? @x = any(1,6), all(2,5), one(3,4); @x = @x.sort; Does sort() carp on junctions, or is it just one of the weird things you have to live with if you're playing with junctions? -- Rod Adams
Re: Junction Values
On Sat, Feb 19, 2005 at 02:40:00PM -0600, Rod Adams wrote: I addressed earlier concept of how does perl know when there are side effects, particularly with the execution path can weave to parts written in pure-parrot. Patrick responded by implying that there was no such side effect protection. I should've included this in my previous post...and write it now simply to promote clarity/completeness: My response in #19212 was intended to show that the side-effect problems being described don't exist, and therefore there isn't any need for side-effect protections such as the ones being proposed. I didn't mean to imply that they would be needed but not available. Pm
#perl6, pugscode.org, and more
Hi. As my today's journal ( http://use.perl.org/~autrijus/journal/23258 ) announced, we have created a #perl6 channel on freenode to discuss everything about perl6, in particular to coordinate development of the Perl6 Compiler and Pugs. All is welcome to join. Also, I've registered http://pugscode.org/ and populated it with some basic information. As the site says, I'm handing out committer bits pretty liberally, so if you are willing to patch things, write tests, and hang out on IRC, please contact the team on IRC or by mail. :) See you on #perl6! Thanks, /Autrijus/ pgpMSwmnhEUku.pgp Description: PGP signature
Re: Junction Values
Rod Adams wrote: Simply put, I want my junctions. Standard in Perl 6. I want my hyper operator superstrength arrays. Standard in Perl 6. I want them both at the same time. Standard in Perl 6. I never want to see implicit threading. Ever. If this is the only stumbling block, then it's easily solved. Instead of ruining junctions by imposing all kinds of complex and annoying hoops and hurdles (i.e. Cuse junctions and Cno junctions), we can just offer a Cno autothreading pragma that prevents any non-explicit junction from autothreading any operator or subroutine. Put it at the top of your code and you'll never get any implicit threading. Damian
Re: Lingering questions about Junctions.
Rod Adams [EMAIL PROTECTED] wrote:
- Can junctions be used as array/hash subscripts?
In an rvalue context, this makes sense, in that you can simply return a
junction of the deferences. But in an lvalue context, this gets dubious
for everything except all() junctions. Consider:
@x = 1..10;
@x[any(4,3)] = 7;
What does @x look like now?
@x[all(4,3,2)] = 7;
makes sense, as long as it means:
@x[4,3,2] »=« 7;
I don't want to even think about what:
@x[none(1,2)] = 7;
does.
The naive meaning of all of these would be::
any(map { @x[$_] = 7 } 4,3)
all(map { @x[$_] = 7 } 4,3,2)
one(map { @x[$_] = 7 } 1,2)
none(map { @x[$_] = 7 } 1,2)
But I'm not sure the naive interpretation is correct.
- Can you have non-scalar junctions?
As the discussions surrounding C .. demonstrated, it's not that hard
for someone to create a situation where a junction of lists might come
into existence. But let's consider something a step beyond.
%x = (a = 1, b = 2, c = 3) | (d = 4, e = 5, f = 6);
@y = %x.keys;
Does this explode, or does @y have something useful in it now?
Do junctive operators force scalar context on their arguments? If so,
we know what happens (you get a junction of arrayrefs); if not, I
suppose it's up for negotiation.
- What does it mean to sort a list of junctions?
@x = any(1,6), all(2,5), one(3,4);
@x = @x.sort;
Does sort() carp on junctions, or is it just one of the weird things you
have to live with if you're playing with junctions?
Good question. Spaceship and cmp aren't quite like the normal boolean
ops, unfortunately; I'm not quite sure what to do about that.
...actually...
Pretend for a moment that cmp is implemented exactly as:
multi sub infix:cmp (Any|Junction $lhs, Any|Junction $rhs) {
return -1 if $lhs lt $rhs;
return 0 if $lhs eq $rhs;
return 1 if $lhs gt $rhs;
}
Then things compare this way:
any(1,6) cmp all(2,5) = -1 (1 is less than both 2 and 5)
all(2,5) cmp any(1,6) = 1 (both 2 and 5 are greater than 1)
all(2,5) cmp one(3,4) = undef (no conditions match)
one(3,4) cmp all(2,5) = undef (no conditions match)
one(3,4) cmp any(1,6) = undef (no conditions match)
any(1,6) cmp one(3,4) = undef (no conditions match)
Happily, all of these are commutative (is this generally true?), and
the Cundefs would be treated as 0s. So this actually would work,
although it would sort in an...interesting...order.
--
Brent 'Dax' Royal-Gordon [EMAIL PROTECTED]
Perl and Parrot hacker
I used to have a life, but I liked mail-reading so much better.
Re: precedence for x and ~
Juerd wrote: According to S03, ~ is tighter than x, while in Perl 5, . was looser than x. No. According to S03, *unary* ~ is tighter than x. *Binary* ~ is looser: symbolic unary ! + - ~ ? * ** +^ ~^ ?^ \ multiplicative * / % x xx + + + ~ ~ ~ additive+ - ~ +| +^ ~| ~^ Damian
Re: Junction Values
Damian Conway [EMAIL PROTECTED] wrote: Yes, it's a side-effect of the new default prohibition on junction assignments (though I'm still working hard to convince everyone that that prohibition cripples junctions and that having to use junctions before you can assign a basic Perl 6 scalar datatype to a variable is an abomination). Point of consideration: is accidentally autothreading over a junction any more dangerous than accidentally looping forever over an infinite lazy list? -- Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker I used to have a life, but I liked mail-reading so much better.
Re: precedence for x and ~
Damian Conway skribis 2005-02-20 11:28 (+1100): According to S03, ~ is tighter than x, while in Perl 5, . was looser than x. No. According to S03, *unary* ~ is tighter than x. *Binary* ~ is looser: symbolic unary ! + - ~ ? * ** +^ ~^ ?^ \ multiplicative * / % x xx + + + ~ ~ ~ additive+ - ~ +| +^ ~| ~^ Oh. I'm ashamed to admit I hadn't looked at the first column. Sorry. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: Lingering questions about Junctions.
Brent 'Dax' Royal-Gordon wrote:
The naive meaning of all of these would be::
any(map { @x[$_] = 7 } 4,3)
all(map { @x[$_] = 7 } 4,3,2)
one(map { @x[$_] = 7 } 1,2)
none(map { @x[$_] = 7 } 1,2)
But I'm not sure the naive interpretation is correct.
A junction as an array index or hash key returns a junction of the
corresponding elements/entries. So:
@x[4|3] = 7
is the same as:
any(@x[4], @x[3]) = 7
But I've repeated stated my strong belief that junctions are scalar values,
*not* lvalues. So the result of that assignment ought to be:
Can't modify constant item in scalar assignment at demo.pl line 1
- Can you have non-scalar junctions?
Do junctive operators force scalar context on their arguments?
Yes.
If so, we know what happens (you get a junction of arrayrefs);
Yes.
if not, I suppose it's up for negotiation.
No. ;-)
- What does it mean to sort a list of junctions?
Brent's analysis is spot on, assuming that Ccmp on junctions works as he
envisaged. Personally, I think I'd implement Ccmp as:
multi sub infix:cmp (Any|Junction $lhs, Any|Junction $rhs) {
return -1 if $lhs lt $rhs;
return 1 if $lhs gt $rhs;
return 0
}
instead, but the differences are marginal: Brent's version treats junctions
that can be equal or greater than as being equal; mine favours the inequality
instead.
Ultimately, of course, a particular list of junctions may not be well-ordered
at all. For example:
sort 1|10, 5|6, 11|0
in which *any* permutation of the list is a plausible sort. So sorting
junctions isn't necessarily always meaningful.
Damian
Re: Junction Values
Damian Conway wrote:
Rod Adams wrote:
I never want to see implicit threading. Ever.
If this is the only stumbling block, then it's easily solved.
Instead of ruining junctions by imposing all kinds of complex and
annoying hoops and hurdles (i.e. Cuse junctions and Cno
junctions), we can just offer a Cno autothreading pragma that
prevents any non-explicit junction from autothreading any operator or
subroutine. Put it at the top of your code and you'll never get any
implicit threading.
Well, allow me to explain what I want in a little more detail, so I can
be sure I'm getting it.
I want to be able to feed a junction to functions that handle it, but I
also want to thread over ones that do not. But I do not want the
decision of which way to go to be made for me.
So, I want to be able to pass a raw junction into C == , because it
understands junctions, and will take care of the threading for me,
likely in a way that's much more efficient than my generalized »«
threading ever could. I do not consider this implicit threading. It's
passing the task of threading off to C == , which itself performs some
form of explicit threading.
But when I'm faced with some function that does not directly support
junctions, or one which does, but not in a way that I like, I want to be
able to thread my junction over it.
I do not think that what you said above is enough to accomplish this. I
believe what I need to separate your threading desires from mine is two
fold:
1) I need my »« modifier which forces explicit threading, which will not
normally be needed under use autothreading; conditions.
2) I need no autothreading; to alter the calling syntax to require »«
when threading is desired (or you can do a .values() and .junctiontype()
and roll your own if you really want to). But I can still pass junctions
around at will, withstanding normal type check requirements.
Then the only argument left is whether use autothreading or no
autothreading should be default. I would, of course, say no
autothreading;, and then turn back on the ability to store junctions.
IMO, no autothreading would provide enough cover for the unsuspecting,
removing the Bad Side Effects problems that spawned Larry's no junction
storage default. At the same time, junctions still have enormous power
via the »«. If people don't want to have to bother figuring out when to
thread for themselves, they can then turn on use autothreading, and
let perl attempt to figure it out for them.
Also, if no autothreading is default, the person new to Perl6 will
always have something to present to investigate to figure out what is
going on. In my code, it'll be the funny looking C »$junction«
things. In your code, it'll be the C use autothreading; at the top of
the page.
The only implementation problem I see is a potential for the »« to be
mis-parsed, since » and « seem to be serving several different roles
these days, but I don't think any of them conflict with this meaning. If
you want to rename »« to something else, I'm open to suggestions. Just
leave it fairly simple.
As for why implementation should be easy (or at least the delta between
your way and my way is easy):
- The functionality of »$junction« has to be defined anyways if
autothreading happens. It's just calling an already existent chunk of code.
- The logic of when to thread becomes:
given $situation {
when marked_with_»«()
{ thread }
when use_autothreading() damians_ouija_board()
{ thread }
default
{ don't thread }
}
And you've already defined how the ouija board works, everything else
should be boilerplate for the compiler/runtime to handle.
This sound reasonable enough?
-- Rod Adams
Re: Lingering questions about Junctions.
On Sun, Feb 20, 2005 at 11:52:09AM +1100, Damian Conway wrote:
But I've repeated stated my strong belief that junctions are scalar values,
*not* lvalues. So the result of that assignment ought to be:
Can't modify constant item in scalar assignment at demo.pl line 1
Yay for sanity. :) It's how pugs implement it, too.
Brent's analysis is spot on, assuming that Ccmp on junctions works as he
envisaged. Personally, I think I'd implement Ccmp as:
multi sub infix:cmp (Any|Junction $lhs, Any|Junction $rhs) {
return -1 if $lhs lt $rhs;
return 1 if $lhs gt $rhs;
return 0
}
Hrm, so Junction.isa(Any) == False? I need to retype print(), say()
and other primitives, then.
Thanks,
/Autrijus/
pgpFXp9YvzxMF.pgp
Description: PGP signature
