|
»
« Return to Thread: Please comment! setup_call_cleanup/3 draft.
Re: Please comment! setup_call_cleanup/3 draft.
by Ulrich Neumerkel
::
Rate this Message:
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
>> 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
« Return to Thread: Please comment! setup_call_cleanup/3 draft.
| Free embeddable forum powered by Nabble | Forum Help |
