A Codewalk for Arc3's first-class(runtime) macros(mzh.im)
mzh.im
A Codewalk for Arc3's first-class(runtime) macros
http://mzh.im/2012/05/28/a-codewalk-for-arc3s-first-class-macro-function-as-macro/
12 comments
Well, here's an example where not having first-class macros is confusing:
in takes any number of arguments, and returns whether the first argument is repeated in the rest of them:
The solution, at least in Arc, is to use mem:
in takes any number of arguments, and returns whether the first argument is repeated in the rest of them:
arc> (in 2 1 2 3)
t
arc> (in 0 1 2 3)
nil
arc> (apply in 2 (list 1 2 3))
Error: "Function call on inappropriate object #(tagged mac #<procedure: in>) (0 1 2 3)"
The solution, at least in Arc, is to use mem:
arc> (mem 2 (list 1 2 3))
(2 3)
Oh you picked a doozie. Apply won't work on macros even if you have first-class macros. Even kernel says, "apply expects an applicative." I spent weeks understanding why. The reason has to do with apply's special status as a dual of eval, and the fact that macros implicitly eval their result in the caller's lexical scope. Here's an example to think about:
(mac foo(a b) `(cons ,a ,b))
(apply foo '(1 (2 3)))
=> (cons 1 (2 3))
=> error: 2 is not a function
I guess the alternative would be to define "apply" as a macro which evals the cons of its first argument and the other list of arguments...
I addressed this approach at the top of the second link: http://arclanguage.org/item?id=15907
Basically you'd have to:
1. eval the list
2. cons the macro to the list, eval to yield the macroexpansion
3. implicitly eval the macroexpansion -- but not eval the elements of the spliced in list because they've already been eval'd once.
Step 3 throws a spanner in the works.
So you might say, fine, let's quote all the elements of the spliced in list. And that'll seem to work for the previous example, but you'll eventually run into an example like this:
Basically you'd have to:
1. eval the list
2. cons the macro to the list, eval to yield the macroexpansion
3. implicitly eval the macroexpansion -- but not eval the elements of the spliced in list because they've already been eval'd once.
Step 3 throws a spanner in the works.
So you might say, fine, let's quote all the elements of the spliced in list. And that'll seem to work for the previous example, but you'll eventually run into an example like this:
(apply = '(x 3))
=> (= 'x '3)
=> error: can't assign to (quote x)
Ah I see.
I've started implementing a Lisp interpreter in C# and I also was going along the path of making everything "first class" by using f-expressions where appropriate. So far my only actual f-expressions are "lambda" and "if" - everything else is bootstrapped as macros or functions.
My "apply" currently expects a function but I was toying with making it "eval" the cons macro... but then "apply" has to become an f-expression instead of just a plain normal function which seemed inelegant so I left it as a function that requires a function.
Reading your story... I think I'll leave it permanently side-stepped!! :-)
I've started implementing a Lisp interpreter in C# and I also was going along the path of making everything "first class" by using f-expressions where appropriate. So far my only actual f-expressions are "lambda" and "if" - everything else is bootstrapped as macros or functions.
My "apply" currently expects a function but I was toying with making it "eval" the cons macro... but then "apply" has to become an f-expression instead of just a plain normal function which seemed inelegant so I left it as a function that requires a function.
Reading your story... I think I'll leave it permanently side-stepped!! :-)
Nice to meet ya! I've been working on a lisp as well: http://github.com/akkartik/wart#readme
BTW, in case you see this: I solved the problem for a large subset of macros. Details: http://arclanguage.org/item?id=16378
> You can't return one from a function, for instance.
Actually you can, for example:
> Non-first-class macros are the way to go for efficiency, at least, and first-class macros themselves are fairly useless.
It's true that non-first-class macros can be more efficiency. But first class macros can benefit from it's nature - a lexical function with environment. Construct such macros can be fancy.
Actually you can, for example:
(assign macro-maker
(fn (x)
(annotate 'mac (fn (y) `(cons ,x ',y)))))
(assign m1 (macro-maker 1))
(disp (m1 a)) ; print (1 . a)
(macex '(m1 3)) ; print (cons 1 (quote a))
> Non-first-class macros are the way to go for efficiency, at least, and first-class macros themselves are fairly useless.
It's true that non-first-class macros can be more efficiency. But first class macros can benefit from it's nature - a lexical function with environment. Construct such macros can be fancy.
There is something very wrong with the concept of 'runtime' macros. How is a 'runtime' macro any better than a function/procedure? TBH, I have no idea what a use case would be for a 'runtime' macro. A macro is generally a compile-time source transformation. If you need that at runtime, use EVAL.
To me it's because they provide a simple way to solve the hygiene problem in an interpreter.
That is, it's easier to implement first-class macros (which allow hygiene) in an intepreter , than it is to implement scheme-style non-first-class hygienic macros...
I only say this because I know how to implement first-class macros, but I don't really understand how Scheme's hygienic macros work...
That is, it's easier to implement first-class macros (which allow hygiene) in an intepreter , than it is to implement scheme-style non-first-class hygienic macros...
I only say this because I know how to implement first-class macros, but I don't really understand how Scheme's hygienic macros work...
One difference is that macros (whether run-time or compile-time) use a call-by-name evaluation strategy. Hence they are a form of lazy evaluation. Functions (in scheme and lisp) are call-by-value IIRC.
> I don't remember. It was either because they were useless or confusing or intellectually inelegant.
Having experienced first-class macros in my own Lisp implementation, I'm inclined to agree. Though there are various promises of efficient implementations scattered through the internet, nobody actually goes into enough detail to explain it. Non-first-class macros are the way to go for efficiency, at least, and first-class macros themselves are fairly useless.