"layered" language approach (was: Re: Constructors (was: RE: About KCP and automatic initialize))

ducasse ducasse at iam.unibe.ch
Thu Sep 18 07:50:51 UTC 2003


Hi brian

What I would like to know is much more at a meta level. For example
what are the problem that we can encounter with a macro systems?

How do we manage the fact that everybody can define its own.... have 
you any experience
wtih that. I remember visiting a company developing in lisp and they 
wanted to get rid of macros
that were generating macro....10 lines was creating 6 pages of code.
So on one hand this would be interesting but what is the price (not the 
technical one
because we are good to access and solve it but the scalability and use 
one).

Stef

On Jeudi, sep 18, 2003, at 08:39 Europe/Zurich, Brian T Rice wrote:

> On Wed, 17 Sep 2003, ducasse wrote:
>
>>> Other systems have found pretty reasonable ways of dealing with it 
>>> (or
>>> at least so I think). For example, using a "layered" language 
>>> approach
>>> could be helpful. On a low level, there is a "kernel language" and on
>>> top of it sit all of the added elements (syntactic or semantic 
>>> sugar).
>>> Pretty much the only thing one needs to make sure is that every
>>> program in the kernel language is also a valid program (with the same
>>> semantics!) on the level above.
>>
>> Yes the scheme macro for example. I would really like to know what is 
>> a
>> good macro system for a Smalltalk.
>
> For reference, Slate has been managing to simplify some language 
> aspects
> such as is the case for its macro system:
>
> http://slate.tunes.org/progman/node8.html#SECTION00033600000000000000
>
> Where preceding a selector with ` will result in applying it to its'
> arguments parse objects (which may be evaluated early or template-
> transformed or directly-manipulated or left alone). Slate has other
> mechanisms as well for syntax extension, but they are all of this 
> flavor:
> no special angle-bracket syntax for type declarations or primitive 
> calls
> are needed.
>
> -- 
> Brian T. Rice
> LOGOS Research and Development
> http://tunes.org/~water/
>



More information about the Squeak-dev mailing list