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
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,
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
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
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
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
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
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
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,
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
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
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
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
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
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 =
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 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
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 + + + ~ ~
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
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
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. :)
21 matches
Mail list logo
