I only noticed it because I was trying to write a macro which expands to multiple def calls. This requires the def's to be inside a do block, which made me question a whole lot about how the AOT compiler works.
On Tue, Apr 15, 2014 at 11:05 PM, Phillip Lord <phillip.l...@newcastle.ac.uk > wrote: > > You need to distinguish between "compiled" and "aot compiled to byte > code". > > As far as I know, all forms are compiled before they are executed. So, > if you type: > > (+ 1 1) > > it is first compiled to bytecode, and then run. It's not executed at > compile time at all; rather when it is evaluated, it is compiled and > then run. If you aot compile, then you are do the same thing, but dump > the bytecode to file. So, you still evaluate the entire top level. > > So, when you say compile, I presume you you mean aot compiled. Macros > have to be run, so the question is should they be expanded but not > evaluated? And what about macros with side-effects? > > And if top level forms are NOT evaluated when loaded what would this do: > > (ns user) > (def x 1) > > (load "user_y") > > === in user_y.clj > (def y 1) > > > Now the AOT would only load the first file in the namespace because > (load "user_y") would not be evaluated. > > Why are you worried about this? Most of the time compilation in Clojure > is an implementation detail, as it is in python. It just happens when it > needs to, and away you go. > > Phil > > > > Andrew Chambers <andrewchambe...@gmail.com> writes: > > Why are the toplevel forms which arent macros executed at compile time? > For > > example Lua can be compiled to bytecode without executing > > its top level calls. > > > > > > On Tue, Apr 15, 2014 at 9:04 PM, Softaddicts < > lprefonta...@softaddicts.ca>wrote: > > > >> Ahem :) > >> > >> a) The fn x does not exist in the universe until you call foo, hence you > >> cannot > >> expect the compiler to known anything about it if it's not called > >> before > >> making any reference to x. > >> > >> b) If you refer to x at the top level (the "universe" above :) before > >> defining > >> it, obviously it does not exist. You might use (declare x) before > >> referring to it. This allows you to define it later at your > >> convenience. > >> > >> c) In general, you should avoid using def/defn within a function. > >> Macros may do that but this is a different story. > >> > >> d) Yes code at the top level is executed, how can you expect > >> the REPL to work interactively if forms are not evaluated first ? > >> A defn expands to a function call, a special form in fact but it > still > >> behaves > >> like a function. Any function call at top level will get executed > >> after being > >> compiled to byte code. > >> > >> Now about the "compilation" step... > >> > >> Traditionally, most Lisps allow you to refer to stuff in interpreted > mode > >> not defined yet hoping that it will get defined by the time you run the > >> code > >> that refers to these undefined things. It can even be something > transient > >> on > >> the stack... oups... > >> > >> You can still compile in other Lisps but this is a special case where > you > >> have to > >> make sure that stuff is defined in some way. You need to add directives > to > >> tell the compiler that this stuff will exist later and that it can > safely > >> refer to it. > >> > >> On the JVM, some underlying byte code has to be generated for any forms > >> typed in the REPL at the top level any reference has to be defined > before > >> hand. > >> > >> There's no other way to generate byte code... there cannot be black > holes > >> waiting to get filled later. > >> > >> Hence the "compilation" phase and the restriction > >> that stuff you refer to are to be defined either directly or using > declare. > >> > >> Hope it explains the compromise. > >> > >> Luc P. > >> > >> > >> > Is there an explanation of how clojure deals with scoping and its > static > >> > checking. It seems to be a hybrid of a static language and a dynamic > >> > language when it comes to compilation. I'll elaborate. > >> > > >> > The following code wont compile: > >> > (defn x [] nil) > >> > (defn y[]) ((x)) > >> > > >> > however this code will compile: > >> > > >> > (defn foo[] (defn x[] nil)) > >> > (defn y[]) ((x)) > >> > > >> > but calling y before foo fails with a runtime exception. > >> > > >> > Also, the following code: > >> > > >> > (println "hello") > >> > (defn -main [args] > >> > (println "world")) > >> > > >> > prints "hello" at compile time > >> > and also > >> > "hello > >> > world" at runtime. > >> > > >> > My conclusions from this is that the static symbol checker is actually > >> > fairly stupid and is just there to provide some simple sanity, and > that > >> all > >> > toplevel code in a namespace > >> > is executed at compile time AND at runtime. Is this correct? > >> > > >> > -- > >> > You received this message because you are subscribed to the Google > >> > Groups "Clojure" group. > >> > To post to this group, send email to clojure@googlegroups.com > >> > Note that posts from new members are moderated - please be patient > with > >> your first post. > >> > To unsubscribe from this group, send email to > >> > clojure+unsubscr...@googlegroups.com > >> > For more options, visit this group at > >> > http://groups.google.com/group/clojure?hl=en > >> > --- > >> > You received this message because you are subscribed to the Google > >> Groups "Clojure" group. > >> > To unsubscribe from this group and stop receiving emails from it, send > >> an email to clojure+unsubscr...@googlegroups.com. > >> > For more options, visit https://groups.google.com/d/optout. > >> > > >> -- > >> Softaddicts<lprefonta...@softaddicts.ca> sent by ibisMail from my ipad! > >> > >> -- > >> You received this message because you are subscribed to the Google > >> Groups "Clojure" group. > >> To post to this group, send email to clojure@googlegroups.com > >> Note that posts from new members are moderated - please be patient with > >> your first post. > >> To unsubscribe from this group, send email to > >> clojure+unsubscr...@googlegroups.com > >> For more options, visit this group at > >> http://groups.google.com/group/clojure?hl=en > >> --- > >> You received this message because you are subscribed to a topic in the > >> Google Groups "Clojure" group. > >> To unsubscribe from this topic, visit > >> https://groups.google.com/d/topic/clojure/VUWTAwOEHS0/unsubscribe. > >> To unsubscribe from this group and all its topics, send an email to > >> clojure+unsubscr...@googlegroups.com. > >> For more options, visit https://groups.google.com/d/optout. > >> > > -- > Phillip Lord, Phone: +44 (0) 191 222 7827 > Lecturer in Bioinformatics, Email: > phillip.l...@newcastle.ac.uk > School of Computing Science, > http://homepages.cs.ncl.ac.uk/phillip.lord > Room 914 Claremont Tower, skype: russet_apples > Newcastle University, twitter: phillord > NE1 7RU > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to a topic in the > Google Groups "Clojure" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/clojure/VUWTAwOEHS0/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
