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 needs smarting up is handing
> in the boolean operator ref. Might a slurpy block work?
>
> if junc($val): {==} {...}
This all reminds me of Haskell's incantation of the same thing:
if (x ==) `any` [1,2,3]
then ... else ...
Which "reads nicely", but it is quite opaque to the naive user.
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.
There is a conflict of design interest here. We would like to maintain:
* Function abstraction
* Variable abstraction
for junctions, but we would also like to maintain genericity with
respect to user-defined operators. Of the proposals so far:
Quantum::Superpositions behavior violates genericity with respect to
user-defined operators.
Autothreading behavior violates function abstraction.
Lexical expansion (i.e. just having the compiler turn $x == 1 | 2 into
$x == 1 || $x == 2) violates variable abstraction.
So, with these three constraints in mind, fmap again comes out on top.
Yes, I'm quite proud of it. Unfortuately, it's ugly, and that's a
constraint too.
There's got to be a good solution lying around here somewhere...
Luke
