On Thu, Oct 15, 2009 at 9:16 PM, Laurent PETIT <[email protected]> wrote: > 2009/10/15 Manuel Woelker <[email protected]> >> >> > How about the compiler just loads classes in a SecurityManager context >> > that >> > won't allow some naughtiness like System.exit()? Then you'd get a >> > CompilerException caused by ExceptionInInitializerError caused by >> > SecurityException rather than have your REPL, IDE, or whatever blow up >> > from >> > code like the above. :) >> >> Well, that seems like quite a hack. And it still doesn't cover things >> like infinite loops (maybe inadvertently). Plus there may well be good >> reasons to do certain things in clinit. What if the initializer throws >> an exception because of some configuration error? >> >> As for macros: These must of course be executed during compilation, >> that's the whole point of macros anyway. I would consider macros to be >> more like "compiler extensions" that happen to live near the code. >> >> I took a closer look at the relevant methods and it seems like it >> should be doable. >> >> Really looking forward to some feedback > > Manuel, > > Two more thoughts: > > 1/ wouldn't your solution limit too heavily the possibilities ? I mean it > seems that you think that only defns, defmacros (and maybe defstructs) and > macro calls can be done at the top level. But even in the top level of a > well behaving namespace, static initializations can occur, some of which may > be necessary for the defined macros to work well. Well, I probably haven't quite grokked the macro system in its entirety, but I would say that if a macro uses functions these functions are "part of the compiler" as well. I still think these few functions could be resolved as needed and then loaded just in time.
> 2/ false sense of security: macros too can be buggy (especially when being > developed) and contain infinite loops, malicious code, etc. . It would place > a false sense of security (concerning the stability of the host compiling > environment) to trust macros totally ? Again, I am not all that familiar with macros so please correct me if I am wrong on these points. a. Macros are few and far between, even a medium sized project should not have more than a handful of macros, but instead build on the standard library of macros that is already available. b. Macros should only do source code transformation and should have no other side effects. This makes it very unlikely that something nasty could happen. c. Macros are part of the compiler. If you write a buggy macro you get a buggy compiler. Hopefully you can find the bug and fix it. Note that writing a macro is quite a different beast from just instanciating a class. I am not trying to deliberately criticise clojure and the process that went into making it. Quite the opposite: I see a huge potential in clojure and especially in its way to solve pressing concurrency issues through immutability and its synchronization constructs. That is why I care. But before I want to commit too much I want to check what I perceive as possible weak spots. Maybe I am dead wrong, and my preconceived notions about what a compiler should or should not do simply clash with the lisp philosophy. But I still haven't heard neither a compelling argument _for_ this mode of operation nor _against_ an alternative class loading free approach. Cheers - Manuel --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to [email protected] Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~----------~----~----~----~------~----~------~--~---
