Please note that in this discussion, I'm not trying to advocate pro/con things, but rather just trying to help you (and me in the process!) see/define the problems you think you see, etc.
So .... more below ... 2009/10/15 Manuel Woelker <[email protected]> > > 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. > I haven't written any medium sized lisp project yet, and so I can't even less pretend I've written any well designed medium sized lisp project. But yes, I also read that it is considered good practice to use macros carefully, and that this generally ends with your project having not so much macros once you have the competence to correctly use higher order functions, for example. > 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. > Yes, but I guess there are some areas where they could shine where accessing external resources is needed, either e.g. for reading external resources in the process, or even copying / transforming external resources, or also checking for the existence of external resources in the classpath, or also write / create new files. Especially thinking about it for when one has to integrate with existing frameworks which may force the user to create a lot of configuration files. For example macros could be used to automatically check/create/update web.xml files on the fly, giving the user immediate feedback if something is wrong in the configuration of the project. But to be honest I haven't seen this kind of use myself, just dreamed about it, so maybe it's not even recommanded to do such things. > 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. > Yes, but in the process, you would have blown away the compiler, and you wanted to avoid that. Writing recursive macros or macro defining macros is hard and I guess it's not so rare to go into infinite loops in the process. > 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. > Your questions are challenging and very interesting. I hope people more competent than me with clojure / lisp in general will take the time to address your points, since we will then all learn in the process : more accurate knowledge/understanding of the weaknesses (and it's important, because as with any lisp : "with great power comes great responsibilities" :). > > 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. > > Indeed, and I will not be the people versed enough in lisp/clojure to be able to give strong arguments. Just sharing thoughts :) --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
