Remembering information during compilation
in [Lisp]
|
Prev: Lisp sucks!
Next: grabbing key presses
From: Spiros Bousbouras on 24 Nov 2009 14:23 On Sun, 22 Nov 2009 14:14:25 +0100 Pascal Costanza <pc(a)p-cos.net> posted: > Spiros Bousbouras wrote: > > > Which brings us back to what I ask above: Is there any established > > way for how such parallel expansion/compilation is supposed to work ? > > To put it otherwise you're saying that my code violates some rules > > but yours doesn't but you're not saying what these rules are , how > > universal they are among implementations and where one could read > > about those rules. And it's not clear what you mean by "side > > effects". Are you saying that things like setf are completely > > forbidden in the code which does the expansion ? > > No, I'm saying that side effects are known to be potential sources for > race conditions, while binding constructs are known to avoid race > conditions. But since you're not explaining what "side effects" means in the context of Lisp you're not really imparting any information. > > Having said that it still seems likely to me that my code will work > > everywhere yours will and that any multithreading Lisp implementation > > worth its salt will create separate copies of the variable a for each > > thread or synchronise access automatically. > > One of the two options is a bet, the other isn't. Indeed. By using the full power of Lisp for writing macros (or anything else) I make sure that my programming will be as quick and enjoyable as possible. On the other hand if I were to adopt your restrictions I would be reducing speed and enjoyment for uncertain benefit. > I know which of the > two I prefer. Yeah , me too. > Good luck with your code, though. Thank you. -- Who's your mama ?
From: Spiros Bousbouras on 27 Nov 2009 11:51
On Tue, 24 Nov 2009 18:54:09 GMT Spiros Bousbouras <spibou(a)gmail.com> wrote: > > ; Working but SBCL specific because of sb-cltl2:macroexpand-all and > ; (require "sb-cltl2") > (require "sb-cltl2") > (let ((a 0)) > (defmacro memory (&rest body) > (prog2 > (incf a) > (sb-cltl2:macroexpand-all > `(symbol-macrolet ((cell ,a)) > ,@body)) > (decf a)))) > > If macroexpand-all expands recursively user defined macros and the > arguments given to macros defined by the implementation but does not > expand the macros provided by the implementation then the above will > still work. So for example if I do > > (macroexpand-all > '(memory ... > (when test-form form))) > > and I get > > (<expansion of memory> > (when <expansion of test-form> <expansion of form>)) Perhaps this would work in the case of when but generally it would give the wrong results since the macro (in place of when) may process the arguments in a completely different manner than macroexpanding the arguments would. > instead of > > (<expansion of memory> > (<expansion of when> <expansion of test-form> <expansion of form>)) > > > it is still adequate for my purposes. [...] > So , come to think of it , a macroexpand-all intended as a debugging > tool would be more useful if it accepted a key argument called :test. > This would be a function which accepts 1 argument which should be a > symbol and returns true or false. macroexpand-all would only try to > expand symbols for which the test function returns true (or all the > symbols if no test function was given). As much as this would be useful, in view of my comment above, it may not be possible. |