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

[Volker Wysk]

Am Montag, dem 18.07.2022 um 21:43 +0100 schrieb 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.

I don't think this would be a good idea. It looks like a powerful tool, as
far as I can tell. But it could easily make the code unintelligible. I'd
rather stay with stock mercury than invent my own programming language. 

Bye,
Volker

> 
> 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 --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://lists.mercurylang.org/archives/users/attachments/20220719/532022bb/attachment.sig>