Compound forms in function position that evaluate to specials have strange semantics

[abridgewater]

The simple example is (`,quote (+ 3 4)) yielding 7.

A more complex example is ((`,lambda '(n) '(+ n 3)) 4) also yielding 7.

What's happening is that the form in the function place is a compound form, so the interpreter declines to treat the overall form as being "special", but it still evaluates to an ATOM_NATIVE for a function that interprets the special form. In effect, it's like the special form except that the parameters are evaluated instead of being passed verbatim.

Possible alternate semantics include:

• Decline to evaluate the parameters if the form in function place evaluates to a "special" form handler, even if it's a compound form.
• Signal an error instead of evaluating the overall form if the form in function place is a compound form that evaluates to a "special" form handler.
• Declare that this case invokes "undefined behavior".

The existing semantic provides a mechanism whereby EVAL could be defined: (defun eval (form) ((`,lambda '() form))), but this closes over FORM, exposing it to the code being evaluated. This also implies explaining the (unusual) semantic in the documentation, and complicates compilation (either to bytecode or to native code), as the interpretive implementation of LAMBDA (for example) requires an interpreter-compatible representation of the lexical environment.

Declining to evaluate parameters complicates compilation (either to bytecode or to native code), as each call site may need to select between evaluating its arguments or passing them verbatim.

Signalling an error simplifies compilation (as the parameters are always evaluated and the only "cost" is to check the evaluated function form to make sure that it's not a special-form interpreter).

Declaring "undefined behavior" is the simplest approach, implementation-wise: We document that the behavior is undefined. A compiler can do whatever, and we can move on to dealing with other issues.

[rexim]

@abridgewater Thank you for submitting an issue with such a detailed explanation! Since we are planing to do some form of bytecode compilation in the future tsoding/ebisp#25 I'd go with "signaling an error" approach.