Can you use a more interesting example? I could just do this if I wanted a oscillating function:
(let (p) #'(lambda () (progn (setf p (null p)) (if p #'+ #'-))))
some of the stack based languages have a similar abstraction of functions being flat arrays of constants. But it isn't parsed so it isn't as easy to use well.
>>14
There isn't that much to them. Just use them a few times and then you will feel the satori building within you, just waiting to abstract and factor enterprise design patterns away into self implemented language features. It doesn't need to be a lisp either, but it should have a comparable macro system.
Wait, what the fuck? Macro setq2 just uses procedure comtran without any issues? But comtran isn't even defined yet! What if someone does something evil/stupid like (let ((comtran evil-procedure)) (setq2 x y z))? What if comtran has an instance of setq2 in it? Is it just me, or macroexpansion-time stuff should live in its own namespace?
>>28
In that case the macro m has lexical scope, and it uses the mf function defined in the let statement for its code transformer. It is powerful to let any user defined lisp function to assist your macro. And we are creeping up on first class macros, but we haven't gotten there yet.
Making them explicit helps with efficiency in the implementation. To maintain performance, they should all be expanded at compile time, and this would be hard if they weren't explicit. Not to mention a macro getting into a place where you only wanted a function would be a hard bug to figure out. But like all things that help performance, it must also cut down on expressive power and possibilities.
>>38 >>37 didn't say that the leakiness isn't justified.
Name:
332012-11-12 4:50
Little did I know that my endeavour would slowly drive me to madness. Seriously, what the fuck. I need some good references on macro magic, and maybe a hug or two.
At the 1980 Conference on Lisp and Functional Programming, Kent Pitman presented a paper "Special Forms in Lisp" in which he discussed the advantages and disadvantages of macros and fexprs, and ultimately condemned fexprs. His central objection was that, in a Lisp dialect that allows fexprs, static analysis cannot determine generally whether an operator represents an ordinary function or a fexpr — therefore, static analysis cannot determine whether or not the operands will be evaluated. In particular, the compiler cannot tell whether a subexpression can be safely optimized, since the subexpression might be treated as unevaluated data at run-time.
tl;dr version:
Le jew PITMAN condemns fexprs because he cannot his way into static analysis. But being Lisp is all about direct manipulation of the AST, who the fuck cares about Le static analysis.
>>41
Lispers have historically strived to make their Jewish Kabbalah magickz both efficient and versatile, and both the intent and the knowledge required to do so is what has set them apart from the scripting languages ``BDFL''s who designed pretty languages with shit semantics and performance.
>>42
Should we believe that, le goog programmateurs will come with über-engineered v8.
Name:
Anonymous2012-11-12 22:50
>>43
doing something at compile time is just an optimization of doing it at run time. Both yield the same behavior so they cannot be distinguished.
Name:
2012-11-13 3:35
Name:
Anonymous2012-11-13 11:48
>>45 doing something at compile time is just an optimization of doing it at run time. Both yield the same behavior so they cannot be distinguished. Please give me a reference with lots and lots of Lisp macro examples with as many interactions between compile- and run-time as possible.
Well, I've been thinking about your dilemma, so I've put together a test.
mac.lisp:
(defmacro confusing (a)
(print (list "is this compile or run time? " a))
a)
(defun client-fun (a b c)
(+ (confusing a) (confusing b) (confusing c)))
[1]> (load 'mac.lisp)
;; Loading file mac.lisp ...
("is this compile or run time? " A)
("is this compile or run time? " B)
("is this compile or run time? " C)
;; Loaded file mac.lisp
T
[2]> (client-fun 1 2 3)
6
[3]>
Looks like compile time in this case. If the macro expansion function had no side effects, then the compile time macro expansion could be seen as constant folding, since all macros are invoked on constant ast literals typed into the program. But in this case the macro causes a side effect, so its evaluation time is significant. When this will happen really depends on the lisp that you are using. First class macro expansions must happen at run time.
Name:
Anonymous2012-11-13 13:02
>>1
Dynamic scoping is shit.
Lexical scoping is superior.
>>56
lexical-let can be implemented using lexical-lambda.
lexical-lambda can be implemented as a tuple together with a reference to the parent activation frame in which the lambda is instantiated.
dynamic scope can be implemented as a hash table of stacks or a stack of hash tables.
Name:
Anonymous2012-11-14 9:14
>>59 reference to the parent activation frame in which the lambda is instantiated.
And how are you going to get that?
>>61
That needs interpreter/compiler hacks, the same way dynamic-scoping-in-lexical-scoped-language needs hacks.
Name:
Anonymous2012-11-15 2:23
>>62
It's lexical scope is more predicable than dynamic scoping. The relationship to the parents is fixed at compile time because the function definitions cannot move around. They have a nested grouping that is fixed and defined for the source file. With dynamic scoping, the parent relationship is dynamic and determined by the state of the function all stack. So the program must be prepared for many different cases when looking up the value of a variable in a parent frame.