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 fact that after $junc = any(1,2,3) there is
no syntactical indication of non-scalar magic in subsequent
uses of $junc e.g. when subs are auto-threaded? I strongly
agree. But I'm striving for a definition where the predicate
nature of the junctions is obvious and the magic under control
of the type system.

The least I think should be done here is to restrict the magic
to happen from within & vars combined with not too much auto-enref
and -deref of junction (code) refs. The design is somewhat too
friendly to the "junctions are values" idea but then not auto-hypering
list operations...

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. The part that needs smarting up is handing
in the boolean operator ref. Might a slurpy block work?

  if junc($val): {==} {...}


  if junc:{==}($val) {...}

Or $val out front

  if $val == :{junc} {...}

which doesn't work with two junctions.

Or reduce syntax:

  if [==] junc, $val {...}

OTOH, explicit overloads of all ops applicable to junctions
might end up where we are now:

  if  $junc == $val {...}

Hmm, wasn't that recently defined as actually beeing

  if +$junc === +$val {...}  #  3 === 1 --> false

Or how else does a junction numerify? Thus the problem only remains with
generic equivalence if explicit, inhomogenous overloads for junctions
exist. And there are no generic <, >, >= and <=. Does a !== or ^^^
antivalence op exist? I guess not.

Reply via email to