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