[cltl3-devel] RFC: CLtL3 Charter

Nikolaus Demmel demmeln at in.tum.de
Wed Sep 2 12:32:14 UTC 2009


Hi,

Am 01.09.2009 um 19:21 schrieb Drew Crampsie:
> 2009/9/1 Gustavo <gugamilare at gmail.com>:
>> <snip>
>
>>
>> A few more topics that could be discussed:
>>
>> (j) Interface to Environments, which is needed in a macro walker  
>> (e.g.
>> cl-walker accesses lexical environments using implementation specific
>> functions).
>
> I'm interested in this as well... but macroexpand-dammit shows one
> doesn't need environments to do a portable walker. However, most lisps
> have CLtL2 environments at least, so i'll add this to the list.
>

Having had to deal with this recently, I think having at least whats  
in CLtL2 would be great. I might be wrong, but I'm not sure you can  
build an full AST - like in cl-walker or arnesi - with the technique  
used in macroexpand-dammit. Although its cool what the macroexpand- 
dammit author has done, it doesn't strike me as very elegant and 'the  
way you would want to do it'.

Although some people in the IRC channel have the opinion that "there  
is nothing you truely need a walker for", I think this view is too  
limited/ignorant. I believe there are (many) valid use cases like  
code introspection/analysis ... How does this relate to the "Editing"  
features meantioned in the draft charta.

Cl-walker not only uses environment augmentation (as in CLtL2  
environments), but also environment introspection. I'm not sure how  
much more effort it would be to include environment introspection  
(both defining a good interface and adoption for implementors) and I  
very much agree with you that for CLtL3 to be successful at all it  
must be as brief and small as possible. On the other hand environment  
access is (unlike say sockets) not something that can be done as part  
of the "standard library". Having said that I think environment  
access is not of the highest priority but should be discussed.

Lisp is all about giving you access to the compiler and I can't see a  
reason why this shouldn't be the case for environments. The rationale  
of not including the CLtL2 environments in the ANSI standard would be  
interesting here.

>> <snip>




More information about the Cltl3-devel mailing list