[m-rev.] Section for the Languge Reference Manual

Volker Wysk post at volker-wysk.de
Thu Oct 13 02:39:25 AEDT 2022


Am Donnerstag, dem 13.10.2022 um 01:52 +1100 schrieb Mark Brown:
> On Wed, Oct 12, 2022 at 11:25 PM Volker Wysk <post at volker-wysk.de> wrote:
> > 
> > Hi!
> > 
> > I've summarized what I've learned about optimization that deletes predicate
> > calls, which may throw an exception. See the recent thread "Existential
> > higher-order type" in mercury-users.
> > 
> > You might want to include it (or an edited version of it) in the Language
> > Reference Manual, as a section of the Exception Handling chapter.
> 
> Thanks Volker! I was also thinking about how to clarify the reference
> manual. I agree with the content of your first three paragraphs,
> except that there are some other effects aside from exceptions, such
> as trace goals (the user most likely wants trace goals to be removed,
> so they can see where the optimization has been applied). Also I was
> going to put the information in a couple of existing places that
> mention this topic, rather than in exception handling.

I think it should go to the exception handling chapter. Or a reference to it
should go there. It's about exception handling (and other topics like trace
goals as well), isn't it? Someone who wants to learn about exception
handling would look here.

> > In the fourth paragraph ("So what...") I've written my thoughts about what
> > to do. You might want to skip or rewrite it.
> 
> I don't agree with adding this, in fact I think we should caution
> against using the style. Consider the following code:
> 
> shoot(Target, !IO) :-
>     valid_target(Target),
>     unsafe_shoot(Target, !IO).
> 
> The problem is that nothing in the declarative semantics says the
> check must come before the unsafe call, when clearly the intent is not
> to shoot first and ask questions later. (I'm guessing this doesn't
> apply to your case from the earlier thread, but I think others are
> likely to try to write code in this way.)

I see the problem... To me it looks like the declarative semantics is
defective, but actually I don't know.

> You can tell the compiler not to re-order conjunctions, but that isn't
> enough - you also have to tell anyone modifying the code that they
> can't reorder conjunctions either, at least not without considering
> the operational semantics first.
> 
> A typical way of writing code that behaves as the above is intended to is:
> 
> shoot(Target0, !IO) :-
>     valid_target(Target0, Target),
>     unsafe_shoot(Target, !IO).

... and Target is a copy of Target0? Something like this:

   ( if Target0 = me then throw(dont_shoot(...))
                     else Target = Target0
   )

> This has a much clearer reading: Target0 is a possibly unsafe target,
> but Target is definitely safe. In addition, the mode system will
> ensure they are executed in the right order.

That's an elegant solution. It should definitely go into the Language
Reference.

> 
> I'll post a diff for the reference manual sometime soon.
> 
> Cheers,
> Mark


Bye
Volker
-------------- 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/reviews/attachments/20221012/3e2544c0/attachment.sig>


More information about the reviews mailing list