On Sun, Feb 20, 2005 at 02:45:36AM +0100, Stefan Lidman wrote:
: Junctions should be on or off by default, I prefer on.
: Having them half-on is bad.
:
: Because if it is half-on people(me) is going to write
: C< if $x == 3 | 5 | 7 { > in N places then have to
: change it and remember to change it
Junctions should be on or off by default, I prefer on.
Having them half-on is bad.
Because if it is half-on people(me) is going to write
C< if $x == 3 | 5 | 7 { > in N places then have to
change it and remember to change it in N-1 places. Oops.
ON or OFF. On please.
/Stefan Lidman
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.
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
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:
>
>
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
