Ticket #1001 (closed enhancement: invalid)

Opened 21 months ago

Last modified 21 months ago

special operators without macro definition

Reported by: informatimago Owned by:
Priority: minor Milestone:
Component: Compiler Version: trunk
Keywords: special-operator macro Cc:

Description

The following special operators don't have a corresponding macro definition.

ccl:nfunction 
ccl:compiler-let 
ccl::ppc-lap-function 
ccl::with-variable-c-frame 
ccl::with-c-frame 
ccl::fbind 

While the standard doesn't specify anything for special operators not in the CL package, it would still be nice if they followed the same rule as for CL macros implemented as special operators:

3.1.2.1.2.2 Macro Forms
An implementation is free to implement any macro operator as a special operator, 
but only if an equivalent definition of the macro is also provided. 

since this would ensure that portable code walkers can be written.

Change History

comment:1 Changed 21 months ago by gb

  • Status changed from new to closed
  • Resolution set to invalid

As the passage you quote states, implementations are required to provide macro definitions of things defined in the standard to be macros (e.g., MULTIPLE-VALUE-BIND) even if that operator is treated specially.

It would not make sense for an implementation to be required to provide macro definitions of things defined to be special operators (or of internal things defined to be special operators in that implementation.) What would the macro definition of GO be ? Of IF ? Of CCL::WITH-VARIABLE-C-FRAME ?

A code walker needs to use specialized knowledge of a special form's syntax and semantics in order to walk that form. This is true regardless of whether the form's operator is IF or CCL::WITH-VARIABLE-C-FRAME or a few dozen other things for which macro definitions generally aren't possible.

comment:2 Changed 21 months ago by informatimago

No, of course, I'm not expecting a macro for CL:GO.

But yes, for CCL::WITH-VARIABLE-C-FRAME.

I don't know what CCL::WITH-VARIABLE-C-FRAME, and since it's not exported, I should not know what it does, and I don't expect it to be documented. But if I write a code walker that expands macros in user code reaching eventually this special operator, how could it proceed?

Now, granted, depending on the purpose of the code walker, the degree of knowledge about this special operator will vary.

For simple uses, we only need to identify what arguments of unknown special operators are code and what are data. So a simple macro like:

(defmacro ccl::with-variable-c-frame (a b c) (ccl::call-variable-c-frame ',a (lambda () ,b ,c)))

here the code walker will know that a is data and b and c are lisp expressions needing to be walked.

Or, if the special operator creates some lexical bindings:

(defmacro ccl::with-variable-c-frame (a b c) (ccl::call-variable-c-frame',a ,b (lambda (,a) ,c)))

Here, the code walker will know that a is data, b is some expression (that it can walk), and that c is some other expression that it can walk in a lexical context where the symbol bound to a as a lexical binding.

Thus, you can always defer to an internal function, and it may not need to do anything.

For more complex uses, you may define the macro as an interpreter for the special operator, using only CL operators. This would allow more complex code walker uses, such as interpreting (or stepping) it. But even in this case, you can defer to a private function as above, only that function would implement the semantics of the special operator. (If you don't give details in a macro about the semantics of a non-standard special operator, the steppers or similar tools will just have to call the function and consider it one step).

Note: See TracTickets for help on using tickets.