Re: Proposal to improve Promises (was Re: Re: The Inbox: Kernel-tonyg.1610.mcz)

If somebody volunteers to refactor Squot to work without
BrokenPromise, will the result also work on older Squeak releases?


Am Mo., 27. Apr. 2026 um 19:54 Uhr schrieb Christoph Thiede via
Squeak-dev <[email protected]>:
>
> Hi Jakob, Tony, Chris, all,
>
> I only found out today that BrokenPromise has been deleted from the trunk. This is quite a breaking change.
>
> For example, one can no longer install Squot (which is recommended in the Preference Wizard) into a recent trunk image because it handles and extends BrokenPromises in multiple places.
>
> Regarding functionality, it is no longer possible to (i) disambiguate an exception raised asynchronously from a regular exception, (ii) access the original signaler context of the inner exception, or (iii) identify the causing promise. Squot seems to only do (i), while I think (ii) and maybe (iii) would be helpful debugging features (when I occassionally witnessed sporadic bugs in Squot in a few years ago, it was already hard enough to find out where they came from because the stack was not preserved, and not even preserving the signaler context or the resolvers will likely worsen such situations).
>
> That being said, I also understand that this extra exception wrappers felt opaque and cumbersome. Evolving APIs vs retaining backward-compatibility always is a tradeoff. Not sure what's more important.
>
> At the very least, why do we have to raise a generic Error rather than a specific one if errorValue is not an exception?
> For the other case, maybe we would need a way to attach multiple tags to exceptions to preserve information such as original signaler contexts or re-signaling promises to the original exception object without removing other information. Like, Exception>>tagDictionary instead of Exception>>tag? Maybe a transparent wrapper around the original exception class that forwards all unknown requests to the original exception (though this would not preserve identity, if that matters)? Maybe something else?
>
> For the upcoming release, I suggest we should do at least one of the following options:
>
> (i) Update Squot to no longer depend on BrokenPromise (it is not actively being maintained right now and a successor is in development, but still our recommendation in the preference wizard)
> (ii) Provide backward compatibility for BrokenPromise (though I don't know how we could achieve that)
>
> Also, we should document this breaking change in the release notes.
>
> Best,
> Christoph
>
> --
> Sent from Squeak Inbox Talk
>
> On 2025-08-12T10:15:25+02:00, [email protected] wrote:
>
> On 8/8/25 03:24, Chris Muller wrote:
> > It might be fine, but please let me know:  If the settlement
> > of one Promise utilizes a variable which refers to another, yet
> > unsettled Promise, and that inner promise is rejected, how should the
> > (outer) Promise respond?  I guess it would be Error Error Error up the
> > Promise chain; likely each signaled from different Processes, is that
> > right?  Or, do we only want one signal from the "root" Promise?
>
> Promises do chain together, yes. The implementation in Squeak already
> does something reasonably sensible (I'm sure there are more corner cases
> waiting to be discovered), drawing heavily on https://promisesaplus.com/.
>
> > But yes, for how *I* use Promises, this proposal is absolutely fine.
>
> Thanks. I'll go ahead and merge then, I think! I have a small queue of
> improvements to Promises that will follow.
>
> Best,
> Tony
>
> Squeak-dev mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
Squeak-dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]