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

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...


Reply via email to