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

[Sean Charles (emacstheviking)]

Ah, Volker, I also forgot to mention this, term rewriting in the samples folder :-

./mercury/mercury-srcdist-22.01/samples/expand_terms.m

If you could bend that to your will then you surely could create some kind of more pleasing record/field updating for your code.
I've played with it but not used it...yet.

Cheers
Sean.



> On 18 Jul 2022, at 19:57, Zoltan Somogyi <zoltan.somogyi at runbox.com> wrote:
> 
> 
> 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.
> _______________________________________________
> users mailing list
> users at lists.mercurylang.org
> https://lists.mercurylang.org/listinfo/users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurylang.org/archives/users/attachments/20220718/a627229c/attachment.html>