Spec confusion about 'sigerr'

[masak]

This:

> (bel '(a . b))
malformed

Is correct/expected, I believe.

It happens because of the (no (proper e)) condition in ev:

(def ev (((e a) . s) r m)
  (aif (literal e)            (mev s (cons e r) m)
       (variable e)           (vref e a s r m)
       (no (proper e))        (sigerr 'malformed s r m)
       (get (car e) forms id) ((cdr it) (cdr e) a s r m)
                              (evcall e a s r m)))

So sigerr gets called. Its definition confuses the heck out of me:

(def sigerr (msg s r m)
  (aif (binding 'err s)
       (applyf (cdr it) (list msg) nil s r m)
       (err 'no-err)))

Can we agree that the (binding 'err s) condition will be false at this point? s at this point is nil, because the only thing that was on the expression stack was (a . b), which ev took off.

What could reasonably have put an err binding in the expression stack? In "The Bel Language": "If there isn't a binding for err, then there's an error in the interpreter itself, and we call err about it." It makes it sounds like it was the interpreter's job to establish a binding for err. But where; how? There really isn't much code happening between the initialization of the one-element expression stack in bel, and this point in sigerr. Does that mean the interpreter is erroneous as specified?

I think bel.bel is wrong here. Maybe this would fix it:

 (def bel (e (o g globe))
-  (ev (list (list e nil))
+  (ev (list (list e nil)
+            (list (list smark 'bind (cons 'err err)) nil))
       nil
       (list nil g)))

[masak]

Having thought about it overnight, I now feel that this is a better/saner fix:

 (def sigerr (msg s r m)
   (aif (binding 'err s)
        (applyf (cdr it) (list msg) nil s r m)
-       (err 'no-err)))
+       (applyf err (list msg) nil s r m)))

That is, the underlying implementation always at least has a global err defined — both your implementation and mine already defines one globally — and it's called with the same convention as a dynamically overriding one.

The only small issue I see with this is that, according to "The Bel Language": "Errors are signalled by calling err with one argument describing the error." But with a bit of squinting, one can take that to mean "one argument describing the error", plus optionally a bunch of others detailing the evaluator's state.

[masak]

Closing this one, since this is a bug in the spec, not in chime.

I expect I'll implement sigerr with the diff above applied (which is effectively what you've done also) — and maybe the user documentation can end up with a note that sigerr is most likely mis-specified and implementations deviate from it.

[masak]

The only small issue I see with this is that, according to "The Bel Language": "Errors are signalled by calling err with one argument describing the error." But with a bit of squinting, one can take that to mean "one argument describing the error", plus optionally a bunch of others detailing the evaluator's state.

No, that's just me being confused; the err function does get exactly one argument; the other arguments are to the (interpreter-internal) function applyf.