<div dir="ltr"><div dir="ltr">Juan,</div><div><br></div>First, thanks for looking at the OMeta part of this... I really wasn't expecting it.  I was mentioning more as an FYI in case you had expected the changes not to have functional/performance impact.  That said, the help is greatly appreciated!<div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Oct 16, 2019 at 7:05 PM Juan Vuletich <<a href="mailto:juan@jvuletich.org">juan@jvuletich.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u>

  
    
    
  
  <div bgcolor="#ffffff">
    Hi Phil,<br>
    <br>
    Today I tried to understand the problems you ran into. The
    attachments are the result of this. To try this, Start Cuis without
    the recent changes (i.e. #3866), then load <a href="http://OMeta2Tests.pck.st" target="_blank">OMeta2Tests.pck.st</a>. Now
    load OMetaStuff*.<a href="http://cs.st" target="_blank">cs.st</a> and UnsavedChangesTo-OMeta2Extensions*.<a href="http://cs.st" target="_blank">cs.st</a>
    attached here. Your tests now pass, and performance seems as usual.
    I suggest updating your repo with this.<br>
    <br>
    My changes do two things. One is to avoid non local returns in
    handler blocks. The other one is about a few places where you did [
    :exception | exception signal ] as the signal handler. Exceptions
    can only be signaled once! I changed them to do [ :exception |
    exception pass ]. This was breaking the exception system if the
    recent changes were loaded.<br></div></blockquote><div><br></div><div>1) Would you be opposed to a #nonLocalReturn: method on Exception?  That seems to me a cleaner and clearer way of doing this.  It's also more consistent with how Exception deals with the other scenarios.</div><div><br></div><div>2) Doh!  I'm not sure if I did the double-signaling or if that was from the original OMeta code.  Either way, it was a dumb thing to do and entirely unnecessary in this case as your changes show.  The 'only signaled once!' part warrants discussion/clarification...</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#ffffff">
    <br>
    Finally, I suggest adding yet another change set to Cuis that could
    break existing but wrong code: 3924*.<a href="http://cs.st" target="_blank">cs.st</a> attached throws an error
    if an exception is signaled twice.<br></div></blockquote><div><br></div><div>I guess it depends on what you are saying:</div><div><br></div><div>1) We think signaling twice is bad form and logically inconsistent and so you shouldn't do it (to me that's not an error, but is something we should capture and *optionally* report to the user... I'm working on another email/changeset related to this case.)</div><div><br></div><div>2) In Cuis, for implementation reasons, signaling twice is an error and can not be done (define twice... read on...)</div><div><br></div><div>While what you are saying re: not re-signaling logically makes sense as something to avoid in general, I don't see anything in the ANSI spec explicitly either allowing or forbidding it.[SPEC]  That's not a big deal as sometimes implementation decisions need to be made but I think we need to be very clear here on what is/isn't allowed:</div><div><br></div><div>1) You can't signal the exception from within its handler block (i.e. you can signal the exception again and/or recycle it, but only *after* the current signal has been handled)</div><div><br></div><div>2) You can't re-signal an Exception ever (i.e. you can recycle but not re-signal... meaning we need to have a method to clear out relevant state for recycling)</div><div><br></div><div>3) You can't re-signal or recycle an Exception ever (i.e. they are single-shot instances)</div><div><br></div><div>(However we go, it seems like comments on the class and relevant methods are in order)</div><div><br></div><div>Seriously, I didn't just make this up.... recycling is a real use case.  If you read my final note on <a href="https://github.com/pbella/OMeta-Cuis">https://github.com/pbella/OMeta-Cuis</a>, the 'original' OMeta implementation actually did recycle exceptions as a performance enhancement.  It did this by re-signaling the existing instance since there was no formal mechanism for recycling.  I removed the feature due to the implementation leaking (on the OMeta side not the Exception side, IIRC) and had planned to re-implement it (sans leak) at some point.  So I'm wondering if that is something that is supported or not.</div><div><br></div><div>This is all near and dear to me because, as you probably noticed, Exception is the spine of OMeta's control flow.  If you change/break one, you probably change/break the other.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#ffffff">
    <br>
    Please review.<br>
    Thanks,<br>
    <pre cols="72">-- 
Juan Vuletich</pre></div></blockquote><div><br></div><div>Thanks,</div><div>Phil</div><div><br></div><div>[SPEC] Just to clarify what I mean here.  In section 5.5.4.2 they explicitly state in the Errors section where #outer cannot be sent from.  If they intended #signal to not be called from somewhere in particular, I would expect (ok, hope) to see that indicated somewhere for #signal as well.  Of course specs aren't perfect and there are any number of reasons why this might not have been stated one way or the other.</div></div></div></div>