[m-dev.] a conditional field update operator

[Zoltan Somogyi]

On Wed, 8 Mar 2017 18:01:50 +1100, Mark Brown <mark at mercurylang.org> wrote:

> One question: is this syntax something that can be redefined, like the
> existing field syntax, or does it always compile down to calls to the
> unconditional field updates (which may themselves be redefined), or
> does it always compile to an ordinary construction like the default
> field update functions?

Let me reformat that to number the alternatives:

1: is this syntax something that can be redefined, like the  existing field syntax, or

2: does it always compile down to calls to the unconditional field updates (which may
    themselves be redefined), or

3: does it always compile to an ordinary construction like the default
    field update functions?

I agree with your vote: I also prefer 2. I think the only advantage of 1 over
the status quo is that you can avoid the When parameter in your example,
which I think is too minor an advantage to justify the work needed for
any change, while 3 unnecessarily throws away existing generality
whose implementation should be readily reusable (though I haven't looked
at the relevant code in a long time).

> I vote that it compiles down to unconditional
> field updates, viz:
> 
> !Term ^ field_list ?= FieldValue
> 
> becomes
> 
> ( if private_builtin.pointer_equal(Term ^ field_list, FieldValue) then
>     true
> else
>     !Term ^ field_list := FieldValue
> )
> 
> Then this code should call the user defined unconditional field
> update, if present.

Agreed for the transformation, though we may need to do something,
such a wrapping a new scope around the if-then-else, to simplify
the optimization of several consecutive conditional field updates
of the same structure, in the usual case of no user-defined field
update function.

I would however vote against using ?= as the conditional update operator.
Its form conveys "condition" well to the reader, but to me, it does NOT
suggest "update".

> Example code mentioned above:

Is this preexisting code, or did you write it for this post?

Zoltan.