On 1/5/06, TSa [EMAIL PROTECTED] wrote:
Jonathan Lang wrote:
Therefore,
$x = 3;
if $x = 1 5 {say 'smaller'}
if $x 1 5 {say 'larger'}
should produce exactly the same output as
$x = 3;
if $x = 1 $x = 5 {say 'smaller'}
This is slightly untrue. because if the
Rob Kinyon wrote:
To me, this implies that junctions don't have a complete definition.
Either they're ordered or they're not. Either I can put them in a =
expression and it makes sense or I can't. If it makes sense, then that
implies that if $x = $y is true, then $x $y is false. Otherwise,
On 1/4/06, Luke Palmer wrote:
The other thing that is deeply disturbing to me, but apparently not to
many other people, is that I could have a working, well-typed program
with explicit annotations.
I don't think it disturbs me... but that might just be because I
don't really understand it.
HaloO,
Jonathan Lang wrote:
Rob Kinyon wrote:
To me, this implies that junctions don't have a complete definition.
Either they're ordered or they're not.
So, is there a number between 0 and 1? Shades between black and white?
When is a 360 degree turn not returning a system into its initial
Me no follow. Please use smaller words?
--
Jonathan Dataweaver Lang
HaloO,
Luke Palmer wrote:
Junctions are frightfully more abstract than that. They only take on
meaning when you evaluate them in boolean context. Before that, they
represent only a potential to become a boolean test.
This is very well spoken err written---except that I would use
beautifully
On 1/2/06, TSa [EMAIL PROTECTED] wrote:
HaloO,
Luke Palmer wrote:
The point was that you should know when you're passing a named
argument, always. Objects that behave specially when passed to a
function prevent the ability to abstract uniformly using functions.[1]
...
[1] This is one
On 1/4/06, Rob Kinyon [EMAIL PROTECTED] wrote:
Luke Palmer wrote:
The point was that you should know when you're passing a named
argument, always. Objects that behave specially when passed to a
function prevent the ability to abstract uniformly using functions.[1]
...
[1] This is one
HaloO,
Rob Kinyon wrote:
I'm confused at the confusion. To me, junctions are just magical
values, not magical scalars. In theory, one should be able to create
junctions of arrays, hashes, or subs just as easily.
my @junc = any( @a, @b, @c );
my %junc = any( %a, %b, %c );
Hmm, and
HaloO,
Luke Palmer wrote:
Which reads nicely, but it is quite opaque to the naive user.
I guess many things are opaque to naive users ;)
Whatever solution we end up with for Junctions, Larry wants it to
support this:
if $x == 1 | 2 | 3 {...}
And I'm almost sure that I agree with him.
Luke Palmer wrote:
Whatever solution we end up with for Junctions, Larry wants it to
support this:
if $x == 1 | 2 | 3 {...}
And I'm almost sure that I agree with him. It's too bad, because
except for that little detail, fmap was looking pretty darn nice for
junctions.
Not really. If
On 1/4/06, Jonathan Lang [EMAIL PROTECTED] wrote:
And I'm almost sure that I agree with him. It's too bad, because
except for that little detail, fmap was looking pretty darn nice for
junctions.
Not really. If I read the fmap proposal correctly,
You didn't :-)
if any($x, $y, $z)
HaloO,
Luke Palmer wrote:
The point was that you should know when you're passing a named
argument, always. Objects that behave specially when passed to a
function prevent the ability to abstract uniformly using functions.[1]
...
[1] This is one of my quibbles with junctions, too.
You mean
On 1/2/06, TSa [EMAIL PROTECTED] wrote:
But I have no idea for this nice syntax, yet. Perhaps something like
my junc = any(1,2,3);
my $val = 1;
if junc( infix:==, $val ) {...}
which is arguably clumsy.
I don't think anyone would waste his time arguing that. :-)
The part that
14 matches
Mail list logo