Richard O'Keefe writes:
> This is perfectly good grammar in some European languages,
> but not in English.
Changed! Thank you.
>One other thing caught my attention.
>
>"setup_call_cleanup(Setup, Goal, Cleanup) is true iff
> call(Setup), call(Goal) is true, and Cleanup is not
> replaced by throw/1."
>
>What do you mean by "replaced?". By whom? By what means?
>When?
I meant it in the sense of e.g.:
:7.12.1 The effect of an error
:When an error occurs, the current goal shall be replaced by
:a goal throw(error(Error_term, Imp_def)) ....
So shall I write throw(Ball)? Unsure.
> Does this mean that
> setup_call_cleanup(Setup, Goal, throw/1)
>is not true, but every other instance is true?
I don't get the point. You can pick here on me writing throw/1 in
place of throw(Ball). Fine. But otherwise?
>Is setup_call_cleanup(1, 2, 3) true?
Type error callable for Setup.
>Does this really mean something like
> setup_call_cleanup(Setup, Call, Cleanup)
> succeeds unless the execution of Cleanup
> is terminated by throwing an exception?
If Cleanup is not replaced by throw/1 or throw(Ball), success or
failure are determined by (call(Setup), call(Goal)) only. Cleanup
might contribute to the answer substitution, but will have no effect
on the outcome described in that sentence. That is not completely
intuitive, as Cleanup and Call might have shared variables, and
Cleanup might instantiate variables. And unification in Cleanup might
fail. But this will not cause failure of setup_call_cleanup/3. It is
a little bit odd, as this is effectively a defaulty unification.
>What if there is an uncaught exception in Setup?
That case is not explicitly mentioned. But Cleanup is only installed
and Call is only called for "each solution" of Setup. (I stuck here
to the meaning of solution in the sense of 13211-1 which I would
rather prefer to call positive answer - since e.g. redundant solutions
and the like are better covered with that notion.)
One reason to avoid such detail was to better focus on the
implementation dependent part, which is the most sensible part here.
Maybe that can be reconsidered. For the moment I do not see it how,
without introducing in the end the notion of a (real) choicepoint -
which I fear will pin down an implementation unnecessarily in one way
or another.
>Does it make sense for
> setup_call_cleanup(throw(up), fail, fail)
>to succeed?
No that should be a system error due to the uncaught 'up'.
>What is
> setup_call_cleanup(fail, true, true)
>supposed to do? Does it _really_ make sense for this
>to succeed?
That should fail indeed. setup_call_cleanup(fail, _,_) is the first
example.
So while I agree with you that these cases should somehow be better
specified, I still believe that these are not the controversial or
sensible cases.
There are not many descriptions for setup_call_cleanup/3 or
call_cleanup/2 around. The original in SICStus 3 is too specific. It
does not use the word choicepoint, but "with some alternatives
outstanding" is not too far away from that.
My first goal was to clarify that part. That is c1. After all, I see
there much more freedom for an implementation than the SICStus
description permits. E.g., why not remove open choice points during
GC, if the alternatives do not match? This might be simpler than
complex indexing. The current draft permits that (without going into
details indeed - it is left implementation dependent - and it seems that
this makes sense only in certain cases - e.g. when there are no shared
variables - like when closing a file etc.). But still a clear
interval is given, where such things might happen.
Thank you in any case! (The next weeks I'll be probably offline)
_______________________________________________
SWI-Prolog mailing list
SWI-Prolog@...
https://mailbox.iai.uni-bonn.de/mailman/listinfo.cgi/swi-prolog
