"layered" language approach (was: Re: Constructors (was: RE:
About KCP and automatic initialize))
ducasse at iam.unibe.ch
Thu Sep 18 10:35:43 UTC 2003
I do not understand why you wrote that: "because I just don't have
> deal with professors needing answers from a mailing list. "
My curiosity was sincer. Now you can believe what you want this is your
not mine. If you do not want to share your experience with your work.
> Being unemployed
> (or self-funding, as it were), I would appreciate basic self-
> sustainability before someone decides that I should be posting several
> pages of content per day without a fee. (Maybe I should preface all my
> emails with links to my resume? :)
If you are looking for PhD positions you can postulate when we will
some in the beginning of the year.
> On Thu, 18 Sep 2003, ducasse wrote:
>> 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?
> Avi Bryant asked this question recently:
> and more significantly in a followup:
> Basically pattern-matching macros are much more tractable in terms of
> consistency for IDE UI purposes than the basic procedural macro.
>> How do we manage the fact that everybody can define its own.... have
>> 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
> The way to deal with or comprehend macros is to grab the output or some
> intermediate form of it (using full or step-wise macro-expansion..
> is a standard lisp tool) and insert that output into your code. Of
> a good Lisp programmer never does this as such, preferring to write new
> macros for a refactoring and using the macro-expansions' comparison to
> debug/unit-test. Or, to write a new common macro that lets you express
> both the new and old pattern in it, and implement them both on top of
> that. It's just refactoring and XP applied at the meta-level.
> One reason that Lisp's tools aren't up to par with Smalltalk's (aside
> the big economic collapse) is that the output code of macro-expansion
> just a bunch of lists usually, so the important meta-information is not
> explicitly transmitted with it. The reasons that are often cited about
> IDE's suffering because macros (or any interesting meta-level code)
> regularity are missing the fact that any meta-level regularity and a
> single substrate IDE framework for managing generative code would be
> to augment and grow the IDE as necessary. (Caveat: this doesn't really
> exist, yet, except in piecemeal among several different research
> At some point, though, you are just talking about generative
> or meta-programming, and you just won't get a magical ability to
> between different custom extensions, just as you can't magically press
> button and transition from one O/R database mapping to another. The one
> important relation that is added is creator/created code consistency:
> there are very few integrated development environments which as a whole
> can know about these effects and handle them well. Dylan's Functional
> Developer seems to have done the best in the tools area.
> (If you want a deeper answer about the state of the art, you need to
> mining resources outside of Squeak and Smalltalk, perhaps into work
> done in Haskell on monadic staged compiler phases or somesuch. The LL1
> mailing list or Citeseer should be good enough for that.)
> One thing I am intending to do with Slate is to use the prototype
> to actually communicate macro information with its generated code as
> annotations on the output source trees: it's really simple to say that
> "this code was generated by a program that preserves these
> invariants", so
> that's that much more information that the compiler/optimizer gets for
> free, or the versioning system. Another thing is to have a mode for the
> IDE where it can show the transition from generating code to generated
> code, in steps or en masse.
> Unfortunately, right now I am mired in getting Slate's self-hosted
> worked out in detail (and keeping the bills paid), so this will take
> time to demonstrate (funding, anyone? :).
> PS: BTW, I am intrigued by a generative programming idea that was
> prototyped by Henrik Gedenryd in Squeak a couple of years ago, called
> Universal Composition, and am still looking for contact info for him.
> Brian T. Rice
> LOGOS Research and Development
More information about the Squeak-dev