HaloO,
Luke Palmer wrote:
Which "reads nicely", but it is quite opaque to the naive user.
I guess many things are opaque to naive users ;)
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.
This actually would be easy if Larry decided that *all* operators
are recognized syntactically and dispatched at runtime. But he likes
to have == strictly mean numeric comparison. Well, with the twist
that the numericy is imposed on the values retrieved from the list
backing the any-junction and the whole thing beeing settled at compile
time syntactically.
But if we assume that all information that is available to the
compiler is available to the runtime as well, then I don't see
any reason why the evaluation of the condition above might not be
a dispatch on the if flow controller multi sub or some such with
some JITing and auto-loading thrown in.
Let me illustrate the point with the well know set of the two
inner operators of nums + and * where * is sort of defined in
terms of +:
3 * 4 --> 12 # symmetric MMD, infix notation,
# atomic evaluation
(3 *)4 --> 4+4+4 # asymmetric prefix, left adjoined operator,
# two step evaluation (addition used for illustration)
# 1: curry lhs to form prefix op
# 2: apply op from step 1
3(* 4) --> 3+3+3+3 # asymmetric postfix, right adjoined operator,
# two step evaluation
I think the compiler decides which of the alternatives is applicable
and generates code accordingly. But why shouldn't it defer the
generation of the semantic tree until dispatch time where the
associativity of the op and the involved types are known? I would
call that syntax tree dispatch or perhaps multi stage MMD. With caching
the results in a local multi this appears as doable to me.
There is a conflict of design interest here. We would like to maintain:
* Function abstraction
* Variable abstraction
With container types these two are embedded into the type system
which I still hope supports arrow types properly. I've sort of developed
the mental model of --> being a co-variant forward flow of control
or program execution and <-- beeing a contra-variant keeping of achieved
state:
--> sub junction / iteration / implication / flow
<-- resub junction / reiteration / replication / keep
<--> bisub junction / equivalence / rw container / sync / snap (shot)
The latter two are not yet Perl 6, and the --> has a contra-variant part
in the non-invocant params, which are of course sync or snap points of
a program. Note that lazy params aren't snapped valueish but typeish in
the sense that the imposed constraints *at that moment* in execution
time hold. Well, and if they don't then we have of course 'ex falso quod
libet' later on :)
There's got to be a good solution lying around here somewhere...
Hmm, operator junctions perhaps? I think that the three relations <, ==
and > are the prototypical order ops. I do not see a priori numerics in
them. This is at best Perl 5 legacy. Note that <=, != and >= are two
element any-junctions from the set of the three primary comparators.
And <=> is a one-junction of all three with succeeding mapping of the
ops to -1, 0 and +1.
Together with negation as center point we get the Fano Plane of the
comparison ops in a crude ASCII chart:
-1|0 0 0|+1
{<=}---{==}---{>=}
\ /
\ {! } /
{<} {>}
none(0,1) <-- -1 \ / +1 --> none(-1,0)
\ /
{!=}
-1|+1 --> none(0)
<=> --> one(-1,0,+1) as circle connecting {<} {==} {>}
can theory theory capture these things in a systematic framework?
--
