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 lis
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
hand
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 C in scope where $x was
assigned to (or the explicit u
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 wond
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 ev
On Sat, Feb 19, 2005 at 02:40:00PM -0600, Rod Adams wrote:
> Damian Conway wrote:
>
> >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;
>
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 belie
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 prote
> 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.
Personally, I've found the thread to be incredibly useful in
(1) understanding Junction
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://pugsco
Rod~
On Sat, 19 Feb 2005 15:20:59 -0600, Rod Adams <[EMAIL PROTECTED]> wrote:
> Poor Mr. Fowles is likely having nightmares figuring out how to summarize all
> of this.
Not really nightmares, more sleepless nights twitching in fear... But
I did skip writing it this week as this thread is the o
Damian Conway wrote:
Rod Adams wrote:
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
assig
According to S03, ~ is tighter than x, while in Perl 5, . was looser
than x.
This can be surprising in things like
"@" x 75 ~ $zap
Which has to be written as
("@" x 75) ~ $zap
in order to make sense.
Was this intentional? What is the rationale?
Juerd
--
http://convolution.nl/maak_j
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.
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:
>
>
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 before you can assign a
> basic Perl 6 scalar datatype to a
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. C and C), we can just offer a C pragma that
prevent
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.
26 matches
Mail list logo
