CL macros and such ... [Re: [Q] CCodeGenerator and inlining]]

Robert Withers withers at vnet.net
Mon Jan 24 01:54:01 UTC 2000


Dwight, Thank you once again.  I am truly in a state of confusion, and
waiting for it to click. :-)  I like it, as it indicates more
interesting things to learn.  I am all over the map here without good
grounding, so I will explore the links you have mentioned and let it
perculate some more.

I was way off on the Blocks!  :-)   Let me try again:  BlockContexts and
BlockClosures are the lambdas of Lisp and the Higher order functions of
Functional Languages.  Closures have a 'copy' of the values in it's
enclosing scope, whereas BlockContexts have open references to the
scope.  Don't quite get that part yet but I will by playing in VW.  Lisp
talks of nested fences as well.  Is it true that this has nothing to do
with CL Macros, other than some powerful combinations of the two?

I am reading CodA, AOP, and I found MethodWrappers.  Very interesting so
far, especially the proposals for MetaClasses in CodA.  It seems that
MethodWrappers implement many Aspect features without changing the
MetaClass -> Class structure.  Again this has nothing to do with CL
Macro behavior, other than I could see CL Macros implementing some of
the things that AOP does.  

The performance stuff is very complicated and it's not the right time
for that yet.  I want to write a plugin and for that I am planning on
doing typed collections.  That will get me to the realm of the
Interpreter and Slang.

So, to CL Macros.  Here is where syntax trees and lazy evaluation come
in.  I walked the compile of a block and a method.  Very cool!  I saw
for myself, that short of adding new syntax, this can't be done with the
current Parser, as it automatically #generates the compiled method.  

If we had a separate MacroParser which registered defined macros in a
repository, then we could send messages to those macros from anywhere. 
The macros could manage their own conversion to bytecodes and patch
themselves.  I think that what is needed for this is a separate
MacroCompiledMethod, or a MacroBlockContext (Closure).  Is this
interesting?

cheers,
Rob

-- 
--------------------------------------------------
Smalltalking by choice.  Isn't it nice to have one!





More information about the Squeak-dev mailing list