Please comment! setup_call_cleanup/3 draft.

[Ulrich Neumerkel]

Dear setup_call_cleanup/3 users!

Rather late, I have finally finished the draft for
setup_call_cleanup/3 to be considered by WG17.
The hardest part has been the implementation dependent
aspects related to determinacy detection.

In the meantime also a use in tipc is no longer implementation
dependent.

Please comment as soon as possible as I would like to
send the draft to uor convener in time.

http://www.complang.tuwien.ac.at/ulrich/iso-prolog/cleanup
_______________________________________________
SWI-Prolog mailing list
SWI-Prolog@...
https://mailbox.iai.uni-bonn.de/mailman/listinfo.cgi/swi-prolog

[Paulo Moura]

On 2009/07/02, at 18:25, Ulrich Neumerkel wrote:

> Dear setup_call_cleanup/3 users!
>
> Rather late, I have finally finished the draft for
> setup_call_cleanup/3 to be considered by WG17.
> The hardest part has been the implementation dependent
> aspects related to determinacy detection.
>
> In the meantime also a use in tipc is no longer implementation
> dependent.
>
> Please comment as soon as possible as I would like to
> send the draft to uor convener in time.
>
> http://www.complang.tuwien.ac.at/ulrich/iso-prolog/cleanup

At the end of the document, you could list all other Prolog compilers  
implementing call_cleanup/2-3: B-Prolog, CxProlog, Qu-Prolog, and XSB  
(hope I'm not missing any compiler). You wrote:

        "Many have call_cleanup/2 but do not guarantee that Cleanup will be  
called eventually."

Which of the Prolog compilers I list above have you tested?

Cheers,

Paulo


-----------------------------------------------------------------
Paulo Jorge Lopes de Moura, PhD
Assistant Professor
Dep. of Computer Science, University of Beira Interior
6201-001 Covilhã, Portugal

Office 3.18  Ext. 3276
Phone: [phone] Fax: [phone]
Email: <mailto:pmoura@...>

Home page: <http://www.di.ubi.pt/~pmoura>
Research:  <http://logtalk.org/> Blog: <http://blog.logtalk.org/>
-----------------------------------------------------------------






_______________________________________________
SWI-Prolog mailing list
SWI-Prolog@...
https://mailbox.iai.uni-bonn.de/mailman/listinfo.cgi/swi-prolog

[Bart Demoen-2]

Hi all,

I am sorry that I can't be in Pasadena, and I appreciate that there
has been an effort to clean up the specification of
setup_call_cleanup/3 - however ...

Can this document be corrected by someone native english please ?
I am really at a loss interpreting some of the sentences.

> Failure of Cleanup is ignored

This makes no sense - ignoring a failure means what ?
[I have insisted on clarifiaction of this sentence before, but it
remains the same - does noone have a problem with it ?]


> as soon as the goal has completed execution.

How soon ? What is "as soon as" ? And what is "goal has completed
execution" ? Say

           p :- q.
           q :- r.
           r :- s.
           s.

The goal being p.
Has it finished between the q and the dot behind it ?
or between the r and the subsequent . ?
...


in the Note
> A processor receiving interrupts between resource allocation and
> call_cleanup/2 is unable to free the resource timely.

This is nonsense or it makes a lot of hidden assumptions.


> Setup is executed protected from interrupts.

Is there a standard (ISO) meaning of "executed protected from
interrupts" - if not, specify. If so, reference the appropriate
section.

> without leaving an effect
???

> with the cleanup handler present
???

> is called exactly once in one of the following moments

Maybe "at" instead of "in" ?
But what follows the previous sentence in the doc, does not specify by
any means a "moment", rather an interval; and "up to the failing of
Goal" is not specified (unless I missed something elsewhere).


> a throw/1 ... whose matching catch/3 is above Goal

What if the Goal is something like the conjunction

        true, catch(...)

is this catch/3 matching the throw ? does 2. apply ?


> the "ball" of throw/1 will be passed

I looked up all meanings of 'passed' and none seems to match what is
meant.


> As a consequence, the "ball" of Cleanup is lost

The meaning of a "ball" being "lost" is not even remotely and/or
intuitively clear - please remove the NOTE



# Cleanup shares bindings and variables with Setup, Goal and the
# continuation. The bindings of Setup are always present.

I hope not always - for instance on backtracking ?

# No further bindings are present in c2 and the latest moment of
# c1.

"latest moment of" a paragraph in the standard ?


I must admit that I have a bias towards ridiculing any attempt to
specify this cleanup mechanism, but please let your specification
attempt not be weakened by that. I am really looking forward to a
serious specification.

I doubt it is possible (just like any attempt to specify compare/3 for
variables was eventually abandoned), but let my opinion not put a
damper on your optimism :-)

Cheers

Bart


Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
_______________________________________________
SWI-Prolog mailing list
SWI-Prolog@...
https://mailbox.iai.uni-bonn.de/mailman/listinfo.cgi/swi-prolog

[Ulrich Neumerkel]

Bart Demoen writes:

>> as soon as the goal has completed execution.
>
>How soon ? What is "as soon as" ? And what is "goal has completed
>execution" ? Say
>
>           p :- q.
>           q :- r.
>           r :- s.
>           s.
>
>The goal being p.
>Has it finished between the q and the dot behind it ?
>or between the r and the subsequent . ?
>...

The answer lies in c1.  We cannot give the precise point in time.  But
we can give an interval.  Here, it is "after the last solution of
Goal".  That means, only from the point on when that solution is found
up to the moment, when execution fails over p. Obviously, most
implementations will in this case take the earliest point in time for
the Cleanup operation.

>> Setup is executed protected from interrupts.
>
>Is there a standard (ISO) meaning of "executed protected from
>interrupts" - if not, specify. If so, reference the appropriate
>section.

Please read the two items just following this sentence.  Interrupts
are implementation dependent.  And the word interrupt is already used
in 13211-1 - in much the same way as here.  Without any further ado.

>But what follows the previous sentence in the doc, does not specify by
>any means a "moment", rather an interval; and "up to the failing of
>Goal" is not specified (unless I missed something elsewhere).

In 1c that moment is within that interval.  The exact moment is
implementation dependent.  That's the point. We cannot say more than
that.  Otherwise we would pin down implementations unnecessarily.
We don't want that.

You really do not understand "[the interval] up to the failing of
Goal"?  It should be good enough for now.  Of course, I would prefer a
better wording.  And later, we can fill in the formal spec.

>> a throw/1 ... whose matching catch/3 is above Goal
>
>What if the Goal is something like the conjunction
>
>        true, catch(...)
>
>is this catch/3 matching the throw ? does 2. apply ?

You might pick on "match".  Taken.  But unifiable (that would be
correct) does not sound right here.  So I took "corresponding call
of..."

However, otherwise I can only refer you to 13211-1 7.8.10.3 b.  It is
used in much the same way.  No need to specify everything from scratch
if we have already 13211-1.

>> the "ball" of throw/1 will be passed
>
>I looked up all meanings of 'passed' and none seems to match what is
>meant.

A more constructive remark would be helpful.  True, 13211-1 does not
use that word.  Maybe we will find something better.

>> As a consequence, the "ball" of Cleanup is lost
>
>The meaning of a "ball" being "lost" is not even remotely and/or
>intuitively clear - please remove the NOTE

Sorry.  "ball" is used in 13211-1 exactly for that kind of term.  It
is not key terminology, of course.  But we need a name for that.  And
exception isn't it (look through 13211-1 to understand that).

And removing that note is not helpful.  Exactly that property is one
of the key changes compared to the original SICStus approach which
caused much headache for reliable operations.  It is very important to
keep that explicit!

>I must admit that I have a bias towards ridiculing any attempt to
>specify this cleanup mechanism, ...

I was positively surprised about the constructivism in your remarks.
After all, I immediately included some of your remarks!

>I doubt it is possible (just like any attempt to specify compare/3 for
>variables was eventually abandoned), but let my opinion not put a
>damper on your optimism :-)

It is impossible to specify setup_call_cleanup/3 entirely.  For this
reason, there are rather large implementation dependents parts in it
which are related to determinacy detection.  I believe that the
current draft contains the minmum of implementation dependence.  It
would be pointless to specify that part exactly - this would only
prevent implementations from considering better optimizations schemes
and bloat the document.

If you do not want to depend on implementation dependent parts, you
will have to use setup_call_cleanup/3 in certain ways.  And I believe
that they are all covered by the current draft.  I went through them
at least one-by-one. TIPC took some time for me to get it.  In the
end, I changed the code (minimally) and simplified the spec.  With
once(setup_call_cleanup(Setup, Goal, Cleanup)) you know Cleanup has
been executed etc.  But you pay a price for that determinacy.  You are
not forced livin' like Larry.

Your point referring to term ordering is well taken: There are some
parts of the language that are better left implementation dependent.

The reason for the inability to specify term order (it was (@<)/2 and
friends not compare/3) was partially related to the fact that there
were different implementations.  Partially to secrecy.  And partially
related to the fact that some implementations simply did not have a
stable term order such that a sorted list remained stable over a
single goal (prominent example: SICStus 3).

Some had local/global variables (as in SWI's ZIP), some (like the
WAM), change more or less spontaneously from local to global, some had
numbered variables but did optimizations that again changed that
order.  Further, the secrecy about the exact head unification (the
crown jewels of a Prolog processor in the early 1990s) did not
simplify communication.  There was only one issue everyone agreed on:
Sorted lists remain sorted for a very very short time.  Actually:
"during the creation of a sorted list" (7.2.1).  That's even less than
I remembered!

In other words: The perfect subject for implementation dependence.
That's why we have that notion!  And don't believe that other
languages do not have such spots.  Better pull them into the
spotlight, such that programmers know what they can rely on.

(I'll be offline from today.  So please do not take silence as
agreement.)

Bart Demoen writes:

>> as soon as the goal has completed execution.
>
>How soon ? What is "as soon as" ? And what is "goal has completed
>execution" ? Say
>
>           p :- q.
>           q :- r.
>           r :- s.
>           s.
>
>The goal being p.
>Has it finished between the q and the dot behind it ?
>or between the r and the subsequent . ?
>...

The answer lies in c1.  We cannot give the precise point in time.  But
we can give an interval.  Here, it is "after the last solution of
Goal".  That means, only from the point on when that solution is found
up to the moment, when execution fails over p. Obviously, most
implementations will in this case take the earliest point in time for
the Cleanup operation.

>> Setup is executed protected from interrupts.
>
>Is there a standard (ISO) meaning of "executed protected from
>interrupts" - if not, specify. If so, reference the appropriate
>section.

Please read the two items just following this sentence.  Interrupts
are implementation dependent.  And the word interrupt is already used
in 13211-1 - in much the same way as here.  Without any further ado.

>But what follows the previous sentence in the doc, does not specify by
>any means a "moment", rather an interval; and "up to the failing of
>Goal" is not specified (unless I missed something elsewhere).

In 1c that moment is within that interval.  The exact moment is
implementation dependent.  That's the point. We cannot say more than
that.  Otherwise we would pin down implementations unnecessarily.
We don't want that.

You really do not understand "[the interval] up to the failing of
Goal"?  It should be good enough for now.  Of course, I would prefer a
better wording.  And later, we can fill in the formal spec.

>> a throw/1 ... whose matching catch/3 is above Goal
>
>What if the Goal is something like the conjunction
>
>        true, catch(...)
>
>is this catch/3 matching the throw ? does 2. apply ?

You might pick on "match".  Taken.  But unifiable (that would be
correct) does not sound right here.  So I took "corresponding call
of..."

However, otherwise I can only refer you to 13211-1 7.8.10.3 b.  It is
used in much the same way.  No need to specify everything from scratch
if we have already 13211-1.

>> the "ball" of throw/1 will be passed
>
>I looked up all meanings of 'passed' and none seems to match what is
>meant.

A more constructive remark would be helpful.  True, 13211-1 does not
use that word.  Maybe we will find something better.

>> As a consequence, the "ball" of Cleanup is lost
>
>The meaning of a "ball" being "lost" is not even remotely and/or
>intuitively clear - please remove the NOTE

Sorry.  "ball" is used in 13211-1 exactly for that kind of term.  It
is not key terminology, of course.  But we need a name for that.  And
exception isn't it (look through 13211-1 to understand that).

And removing that note is not helpful.  Exactly that property is one
of the key changes compared to the original SICStus approach which
caused much headache for reliable operations.  It is very important to
keep that explicit!

>I must admit that I have a bias towards ridiculing any attempt to
>specify this cleanup mechanism, ...

I was positively surprised about the constructivism in your remarks.
After all, I immediately included some of your remarks!

>I doubt it is possible (just like any attempt to specify compare/3 for
>variables was eventually abandoned), but let my opinion not put a
>damper on your optimism :-)

It is impossible to specify setup_call_cleanup/3 entirely.  For this
reason, there are rather large implementation dependents parts in it
which are related to determinacy detection.  I believe that the
current draft contains the minmum of implementation dependence.  It
would be pointless to specify that part exactly - this would only
prevent implementations from considering better optimizations schemes
and bloat the document.

If you do not want to depend on implementation dependent parts, you
will have to use setup_call_cleanup/3 in certain ways.  And I believe
that they are all covered by the current draft.  I went through them
at least one-by-one. TIPC took some time for me to get it.  In the
end, I changed the code (minimally) and simplified the spec.  With
once(setup_call_cleanup(Setup, Goal, Cleanup)) you know Cleanup has
been executed etc.  But you pay a price for that determinacy.  You are
not forced livin' like Larry.

Your point referring to term ordering is well taken: There are some
parts of the language that are better left implementation dependent.

The reason for the inability to specify term order (it was (@<)/2 and
friends not compare/3) was partially related to the fact that there
were different implementations.  Partially to secrecy.  And partially
related to the fact that some implementations simply did not have a
stable term order such that a sorted list remained stable over a
single goal (prominent example: SICStus 3).

Some had local/global variables (as in SWI's ZIP), some (like the
WAM), change more or less spontaneously from local to global, some had
numbered variables but did optimizations that again changed that
order.  Further, the secrecy about the exact head unification (the
crown jewels of a Prolog processor in the early 1990s) did not
simplify communication.  There was only one issue everyone agreed on:
Sorted lists remain sorted for a very very short time.  Actually:
"during the creation of a sorted list" (7.2.1).  That's even less than
I remembered!

In other words: The perfect subject for implementation dependence.
That's why we have that notion!  And don't believe that other
languages do not have such spots.  Better pull them into the
spotlight, such that programmers know what they can rely on.

(I'll be offline from today.  So please do not take silence as
agreement.)

_______________________________________________
SWI-Prolog mailing list
SWI-Prolog@...
https://mailbox.iai.uni-bonn.de/mailman/listinfo.cgi/swi-prolog