You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
; '%closure (a = {}) {}'
closure.c:72: assertion failed (k == nWord || k == nQword || k == nPrim)
(note the quotes).
I've actually triggered this several times myself; I'm surprised I didn't connect the dots before now.
My goal at the time was to reduce the exponential blowup of quote characters (you know how when you print some heavily-overloaded functions you end up with something like %closure (fn-foo = ''''''''$&foo'''''''') {...}?) What happens when you do that, though, is that the next time the shell tries to parse a %closure string, the extract() function expects one of the following three options as every definition: a word, the pseudo-primitive $&nestedbinding, or anything else wrapped up in quotes; so giving it something else, like the unquoted {} in the example above, causes it to choke.
I'm not quite sure how you managed to trigger the behavior without either a hand-crafted %closure string or editing the source, though. Impressive!
The most "complete" fix seems to be doing a full-on glom() of the definition during extract(). It's a little tricky, though, because glom() expects the GC to be on, while extract() expects the GC to be off. Maybe that's a sign that glom() during extract() isn't actually correct. It might also be reasonable to just make some more of the tree types -- nLambda, nThunk, nPrim, nList, maybe nConcat -- valid and not worry (yet) about fully glomming things like nCall.
error:
Produced by my somewhat psychotic startup file after two 'es -l':
The text was updated successfully, but these errors were encountered: