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 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): {==} {...}
Or
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.
--
