[m-users.] Concise syntax for initialising and updating discriminated union types

[Zoltan Somogyi]

2022-07-19 04:35 GMT+10:00 "Volker Wysk" <post at volker-wysk.de>:
>> > 2. Some concise way to update multiple fields, like above. Maybe the
>> > compiler could additionally generate field update predicates for the fields
>> > (like above), similar to field update functions.
>> 
>> This would be easier to implement, but one would want to design
>> any such new feature carefully. For example,
>> 
>> - how do you specify which subset of the fields you want setter predicates for
>>   (in many situations, some fields should be read-only).
> 
> Couldn't this be done the same way as it's done for setter functions?

>From the user's point of view, you could: you would write all the declarations,
and the compiler would write all the definitions for you. From the compiler
writer's point of view, extending the mechanism we now use to implement
field access functions (both getters and setters) would not really work.
This is because unnamed field get and set functions are just shorthand for unifications,
which do not need entries in the predicate table, but getter and setter *predicates*
obviously do need such entries. The bulk of the work of implementing getter
and setter predicates would be setting up those predicate table entries,
which is quite different from the existing code that rewrites things that look like
calls to getter/setter functions into unifications.
 
>> You would also want some mechanism to control the names of the generated
>> predicates, though a naming scheme consisting of {get,set}_<fieldname>
>> would be a good default.
> 
> You could just use the field name as the predicate name in both cases, since
> they differ in the arity.

Again, you could, but each line of code is read far more often than in it is
written, so the wise tradeoff is to make reading easier, even if it costs a few
keystrokes.

Zoltan.