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

[Mark Brown]

For review by anyone.

On Thu, Oct 13, 2022 at 2:39 AM Volker Wysk <post at volker-wysk.de> wrote:
>
> 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.

On second thoughts, I think you're right. I've put the main example in
Exception handling and also mention it in Trace goals.

The definitive discussions are in Determinism, where we describe the
mode-determinism assertions that make the optimization valid, and
Formal semantics where we define predicate strictness.

>
> > > 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.

It's highly desirable for conjunction to be commutative in the
declarative semantics, and as such it wouldn't be able to capture the
intent of the programmer in this case. However, the example could be
an argument as to why the strict sequential semantics (or Prolog's
operational semantics, for that matter) is better than the strict
commutative semantics - that's why there are options to control this
choice.

>
> > 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.

Done. Review is attached.

Cheers,
Mark

>
> >
> > I'll post a diff for the reference manual sometime soon.
> >
> > Cheers,
> > Mark
>
>
> Bye
> Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: diff
Type: application/octet-stream
Size: 13656 bytes
Desc: not available
URL: <http://lists.mercurylang.org/archives/reviews/attachments/20221013/0f545e51/attachment.obj>