Re: Junctions again (was Re: binding arguments)

2006-01-06 Thread Markus Laire
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 sligh

Re: Junctions again (was Re: binding arguments)

2006-01-05 Thread Jonathan Lang
Me no follow. Please use smaller words? -- Jonathan "Dataweaver" Lang

Re: Junctions again (was Re: binding arguments)

2006-01-05 Thread TSa
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 s

Re: Junctions again (was Re: binding arguments)

2006-01-05 Thread David Green
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.

Re: Junctions again (was Re: binding arguments)

2006-01-05 Thread Jonathan Lang
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. Otherwi

Re: Junctions again (was Re: binding arguments)

2006-01-05 Thread Rob Kinyon
On 1/4/06, Luke Palmer <[EMAIL PROTECTED]> wrote: > Of course, this was introduced for a reason: > > sub min($x,$y) { > $x <= $y ?? $x !! $y > } > sub min2($x, $y) { > if $x <= $y { return $x } > if $x > $y { return $y } > } > > In the presence of junctions,

Re: Junctions again (was Re: binding arguments)

2006-01-04 Thread Jonathan Lang
Luke Palmer wrote: > Of course, this was introduced for a reason: > > sub min($x,$y) { > $x <= $y ?? $x !! $y > } > sub min2($x, $y) { > if $x <= $y { return $x } > if $x > $y { return $y } > } > > In the presence of junctions, these two functions are not equ

Re: Junctions again (was Re: binding arguments)

2006-01-04 Thread TSa
HaloO, Luke Palmer wrote: But junctions are so "special", that this abstraction wouldn't work. Well my point is that I dought that it is tractible for the compiler to come up with the dwimmery to pull the invocation of .values on the return value out of toomany and leave the cardinality check

Re: Junctions again (was Re: binding arguments)

2006-01-04 Thread TSa
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 this

Re: Junctions again (was Re: binding arguments)

2006-01-04 Thread Luke Palmer
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] T

Re: Junctions again (was Re: binding arguments)

2006-01-04 Thread Rob Kinyon
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] > > ... > > [

Re: Junctions again (was Re: binding arguments)

2006-01-04 Thread TSa
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

Re: Junctions again (was Re: binding arguments)

2006-01-03 Thread Luke Palmer
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,

Re: Junctions again (was Re: binding arguments)

2006-01-03 Thread Jonathan Lang
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 re

Re: Junctions again (was Re: binding arguments)

2006-01-03 Thread TSa
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

Re: Junctions again (was Re: binding arguments)

2006-01-02 Thread Luke Palmer
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. :-) > T

Junctions again (was Re: binding arguments)

2006-01-02 Thread TSa
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 the