Better then loop/iterate?

[karol.skocik]

I have been a little annoyed by this: Having flets, lets, macrolets and symbol-macrolets separate all the time has disadvantages.

1) More nested then need be, implying more parenthesis, more depth of indentation.

2) Sometimes need lets or flets in some specific order, causing more nesting.

So it might be better to use macros that create all these macros at the same time, and it seems to be the only disadvantage of that is that it punishes the user a little less when he doesn't create sub functions fast enough. I don't think that is worth it; programmers need to recognize that themselves anyway.

There are a bunch of ways to do this:

• With a macro with a specific variable(of any *let) creation area. The umac this thread was begun with somewhat does that.(Looking at the source code, i see i didn't write it so it can fix (2) currently, easily fixed, and then it'll do it.) Advantages is clear distinction between variables and body, and separate namespace for 'macros to create variables'.(def-umac) You could make a with-slots for the umac, for instance. (maybe not so inferior to iterate after all.)
• An iterate-like approach, working in a scope-like manner. here the advantage is that regular macros can make variables. It likely needs a 'scope-transparant'

There is a metabang-bind project. It does what you describe and is extensible.

I guess mine in better: http://github.com/ks/X.LET-STAR

[Jasper]

I don't think your approach is better.(although the code is good!) The way Metabang bind and let-star both are capable of what denest does seems to expose to me that denesting is the better route.

If let-star exposed define-binder, then you could make one that looks a little like denest:

Code: Select all

(define-binder (:macro (name symbol) args decls body)
  `(,name ,@args ,@body))

And of course you can 'import' macros to various symbols, stuffing the arguments into the name and args. (And metabang bind probably can do it too, but i haven't checked.)

A few disadvantages of define-binder versus denest:

• You have to explicitly 'import' macros.
• define-binder requires more learning then just making a regular macro and plugging it into denest, or using def-denest-macro for utilizing the keywords also. (def-denest-macro works just like defmacro, except the name must be a keyword, and it only works in denest or when using it via use-denest-macro.
• The arguments for let-star are limited to the form (var val) (Rather annoying when using the :macro like that.)

Note that i made a little alteration to the basic idea of denest.

Code: Select all

(defmacro denest (&rest forms)
  (if (null (cdr forms))
    (car forms)
    `(,@(car forms) (denest ,@(cdr forms)))))

PS: i'd have updated autodocs, git and little website for this, but damn berlios.de is down, i think i am changing 'home'. (Or maybe my own website..) Github good?

PS2: Use doc-strings?! (documentation is setfable, if you don't want it in the code.) and why make parse-binding a flet? You can just not export it too. (Like you did with process-lambda-list-with-ignore-markers)