Hi Jakob,
alright, so would you like to upload a patch to the inbox? Should anyone else review it? :-)
Best,
Christoph
---
Sent from Squeak Inbox Talk
On 2023-08-19T11:44:55+02:00, jakres+squeak@gmail.com wrote:
> Hi Christoph,
>
> Am Fr., 18. Aug. 2023 um 21:06 Uhr schrieb <
> christoph.thiede(a)student.hpi.uni-potsdam.de>:
>
> >
> > I might be a little bit late to the party,
>
>
> Well, if the party is still going on after three years, it must be a good
> one... ;-)
>
>
> > Is it true that nothing newer has happened on this issue after this
> > message?
> >
> >
> Not entirely sure, but if you still experience the problem, it
> apparently has not changed. I also still have #halt-s in the Promise
> methods in my working images so that I can deal with errors.
>
>
> > > The behavior of non-local exits from unwind contexts is undefined in the
> > Smalltalk ANSI standard (just like resume: or return: in a defaultAction,
> > or not sending resume: or return: in an on:do: exception handler at all --
> > VA Smalltalk interprets that as resume, while Squeak does return, for
> > example).
> >
> > I don't understand the context of this note, but speaking in terms of
> > Squeak,
> >
>
> To implement it "Squeak-conformant" is probably enough. In 2020 it was not
> long ago that I worked with VA Smalltalk and I was regularly annoyed by
> non-portable (not "ANSI-conformant") code. The chances that somebody will
> want to use the Squeak implementation of Promises in another Smalltalk are
> probably quite slim. Nevertheless, I have made it a habit to always use
> return: or resume: in handler blocks.
>
>
> > One additional note: What should happen if you terminate the active
> > process from a promise (or do the same from the outside)? Should this also
> > reject this promise, or should it be scheduled later again? However, this
> > is likely a different story, so let's not add another dependency to this
> > issue.
> >
> > Agreed. Intuitively it sounds right to eventually reject something that
> was aborted. But since we do have multi-processing/-threading, the Promise
> might yet be fulfilled by another process. Or not... depends on the
> application. We might not be able to find a general answer that suits all
> use cases. You could also think about rejecting unfulfilled promises when
> they are garbage-collected... but JavaScript does not do that either, as
> far as I know.
>
> Maybe the answer is: just don't do that in your application. :-)
>
> Kind regards,
> Jakob