There's a way to reconcile all of this: if you treat the "environment as a value" then I believe you can achieve both:
- Incremental REPL-style commands that work immediately in the current environment - Arbitrary declaration order in files >From a technical perspective, the environment would contain deferred compilation units that get compiled only when the symbols they require are all defined. This could be managed fairly efficiently using a dependency graph maintained by the compiler. Automatic recompilation of dependency graphs would also be possible, I believe - this would potentially allow some fun/scary stuff if you redefine things at runtime but I think it would work. I wrote about this idea a while back, there wan't very much interest at the time but I still think it's a powerful approach that could be applied to Clojure: https://groups.google.com/d/topic/clojure-dev/S8BawG7nzJA/discussion On Wednesday, 21 August 2013 00:54:07 UTC+8, Luc wrote: > > REPL versus compilation in Lisp have for many decades been two different > things. > > In the REPL, you were allowed to refer to symbols that were undefined in > the current > lexical scope, hoping that at runtime they would eventually exists some > where > on the stack. > > To compile such code you needed to add declarations for this > stuff not in the lexical scope of the compiler to tell it that it would be > defined later > else where. Either later in the same file or in a different one, this did > not matter. > Otherwise the compiler would simply fail. > > Compilation was an odd thing in Lisp initially and it was sufficiently > different from > the REPL to require twists in your code when you wanted to compile it. > It was seen as a second step, after dev had been done in the REPL. > > The REPL is there to swallow forms which are unrelated. > The kind of compilation you would like to see requires something more > (the "file approach ?"). > > If we fall too much on the "compilation/optimization" > side, then this relative independence of forms will eventually break and > create it's own set of problems at the REPL. > > Yes Lisps were designed mainly for REPL interaction, compiling came > afterward. > I was a witness of this era mainly because I am a dinosaur :) > > Clojure's approach is somewhere closer to the compilation side in view of > the > requirements of it's supporting container but I do not think > that it can get much closer without breaking some of that dynamic REPL > stuff that > speeds up development and that we like. > > Luc P. > > > Tim Visher <tim.v...@gmail.com <javascript:>> writes: > > > > > On Mon, Aug 19, 2013 at 11:09 PM, Armando Blancas > > > <abm2...@gmail.com<javascript:>> > wrote: > > >>> I'll point out as well that though I thought Yegge's criticisms of > > >>> Clojure were a bit polemical (I guess that's his style), the single > > >>> pass compiler issue was one of his biggest gripes, and I do think it > > >>> still rings true. I feel like I have to babysit clojure in this > > >>> regard, when I usually feel like clojure is babysitting me! :) > > >> > > >> Have you seen this? https://news.ycombinator.com/item?id=2467359 > > > > > > That's what I was referring to. Was there something specific about it > > > that you wanted to call out? :) > > > > > > Actually, that's quite interesting, and I hadn't seen it before. > > > > I can understand the reasons why forward declaration makes the > > implementation of clojure easy, but it does seem to be pushing the > > burden onto the programmer, rather than the language designer. I'm > > particularly not convinced by the argument that "Lisps were designed to > > receive a set of interactions/forms via a REPL"; forward declaration > > introduces another circumstance where the state of your REPL can get in > > a twist: your source might look like this... > > > > (def y) > > (defn x[] y) > > > > then get changed to > > > > (defn x[] y) > > (def y) > > > > and working quite happily *until* you restart the REPL. Re-starting just > > in case is a problem with most REPLs, and this doesn't help. On the > > whole, I think I prefer compile warnings, rather than everything > > breaking. > > > > I seem to have stirred up a bit of a nest. > > > > Phil > > > > -- > > -- > > You received this message because you are subscribed to the Google > > Groups "Clojure" group. > > To post to this group, send email to clo...@googlegroups.com<javascript:> > > Note that posts from new members are moderated - please be patient with > your first post. > > To unsubscribe from this group, send email to > > clojure+u...@googlegroups.com <javascript:> > > 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+u...@googlegroups.com <javascript:>. > > For more options, visit https://groups.google.com/groups/opt_out. > > > -- > Softaddicts<lprefo...@softaddicts.ca <javascript:>> 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 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/groups/opt_out.
