Open wryun opened 12 years ago
Oh! Here's a rather simpler repro:
; '%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':