<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Ah, Volker, I also forgot to mention this, term rewriting in the samples folder :-<div class=""><br class=""></div><div class=""><font face="Menlo" class="">./mercury/mercury-srcdist-22.01/samples/expand_terms.m</font></div><div class=""><br class=""><div class="">If you could bend that to your will then you surely could create some kind of more pleasing record/field updating for your code.</div><div class="">I've played with it but not used it...yet.</div><div class=""><br class=""></div><div class="">Cheers</div><div class="">Sean.</div><div class=""><br class=""></div><div class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On 18 Jul 2022, at 19:57, Zoltan Somogyi <<a href="mailto:zoltan.somogyi@runbox.com" class="">zoltan.somogyi@runbox.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><br class="">2022-07-19 04:35 GMT+10:00 "Volker Wysk" <<a href="mailto:post@volker-wysk.de" class="">post@volker-wysk.de</a>>:<br class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class="">2. Some concise way to update multiple fields, like above. Maybe the<br class="">compiler could additionally generate field update predicates for the fields<br class="">(like above), similar to field update functions.<br class=""></blockquote><br class="">This would be easier to implement, but one would want to design<br class="">any such new feature carefully. For example,<br class=""><br class="">- how do you specify which subset of the fields you want setter predicates for<br class=""> (in many situations, some fields should be read-only).<br class=""></blockquote><br class="">Couldn't this be done the same way as it's done for setter functions?<br class=""></blockquote><br class="">From the user's point of view, you could: you would write all the declarations,<br class="">and the compiler would write all the definitions for you. From the compiler<br class="">writer's point of view, extending the mechanism we now use to implement<br class="">field access functions (both getters and setters) would not really work.<br class="">This is because unnamed field get and set functions are just shorthand for unifications,<br class="">which do not need entries in the predicate table, but getter and setter *predicates*<br class="">obviously do need such entries. The bulk of the work of implementing getter<br class="">and setter predicates would be setting up those predicate table entries,<br class="">which is quite different from the existing code that rewrites things that look like<br class="">calls to getter/setter functions into unifications.<br class=""><br class=""><blockquote type="cite" class=""><blockquote type="cite" class="">You would also want some mechanism to control the names of the generated<br class="">predicates, though a naming scheme consisting of {get,set}_<fieldname><br class="">would be a good default.<br class=""></blockquote><br class="">You could just use the field name as the predicate name in both cases, since<br class="">they differ in the arity.<br class=""></blockquote><br class="">Again, you could, but each line of code is read far more often than in it is<br class="">written, so the wise tradeoff is to make reading easier, even if it costs a few<br class="">keystrokes.<br class=""><br class="">Zoltan.<br class="">_______________________________________________<br class="">users mailing list<br class=""><a href="mailto:users@lists.mercurylang.org" class="">users@lists.mercurylang.org</a><br class="">https://lists.mercurylang.org/listinfo/users<br class=""></div></div></blockquote></div><br class=""></div></div></body></html>