Hi all,

would it be okay if I merge this proposal? In a nutshell, I just unified and updated the documentation of the wording of the compiler interface, plus made sure that failBlock will only be used in interactive compilation. See also the downstream dependencies of this patch in the inbox (Squeak Inbox Talk helps). Basically a small clean-up. :-)

Best,
Christoph

---
Sent from Squeak Inbox Talk

On 2020-11-14T18:28:51+00:00, christoph.thiede at student.hpi.uni-potsdam.de wrote:

> Thank you for the feedback, Jakob! I always try to be as specific as possible in the version message, but this one was apparently not precise enough ...
> 
> 
> > what is their reason or purpose?
> 
> 
> I have been wondering a couple of times when exactly the failBlock passed to a compilation process is evaluated, or rather whether it might be evaluated at all. After analyzing the parser code, I found out that failBlock is evaluated *almost never* provided that the compilation is not interactive, i.e. whenever the specified requestor is nil. I have documented this insight in all relevant public method comments.
> 
> 
> > What was that single precedent case?
> 
> 
> There was one exception to this (until now) undocumented rule: Parser >> #notify:at: sent an unconditional #fail "for failure setting up syntax error" which appears to be an internal and thus very rare error only. I have added an interactive check at the relevant place to make sure that the following invariant now is always valid:
> 
> 
> If the requestor is nil, failBlock will not be evaluated under any circumstances.
> 
> 
> This invariant should help us to simplify several users of the compiler API (in the Trunk as well as in external packages) to reduce the number of code branches that need to be honored. For one example of many, in ClosureCompilerTest >> #testDecompiledDoitMethodTempNames, we now know that we don't have to care about the failBlock so the [self error: 'compilation error'] there is officially redundant. And yes, in the future we also might want to introduce a simple #compile:in: convenience method for this purpose. :-)
> 
> 
> I hope I could answer your questions ... :-)
> 
> 
> Best,
> 
> Christoph
> 
> ________________________________
> Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von Jakob Reschke <forums.jakob at resfarm.de>
> Gesendet: Samstag, 14. November 2020 16:58:59
> An: squeak-dev at lists.squeakfoundation.org
> Betreff: Re: [squeak-dev] The Inbox: Compiler-ct.452.mcz
> 
> > Reworks public Compiler interface and documentation:
> >
> > - Parser: Do not use #fail in the event of an internal error unless compilation is interactive. This was a single precedent case.
> > ...
> > - Provide new convenience selectors #compileNoPattern: and #compileNoPattern:in: on Compiler instance side.
> 
> Independent of whether these changes are good or bad: what is their
> reason or purpose? What was that single precedent case? I like to read
> such things in the commit message. :-)
> 
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20201114/735ebbab/attachment.html>
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20220505/9f0165e1/attachment.html>