On Thursday, July 9, 2015 at 4:14:32 PM UTC-4, Brandon Taylor wrote: > > Ok, here's where I'm getting hung up. You said that the compiler figures > out the creation/lifetime of all variables at compile time. So does that > mean there's a list like: > > a maps to location 0 and exists from line 3 to line 9 > b maps to location 1 and exists from line 7 to line 9 > a maps to location 10 and exists from line 7 to 9? > > and that to map variables to locations on any particular line, the > compiler works its way up the list, >
Yes, more or less. > > This is perhaps even more helpful than the environment. The environment is > immediately and completely determinable at any point in the program. This > could make it possible to walk back in time even within the same scope. > Could you expand on what you're thinking of? This kind of compile-time environment could conceivably be exposed to macros. Common Lisp had proposals along that line ( https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node102.html) but as far as I can tell, it was too complicated and not useful enough, so it was axed/neutered at some point in the standardization process. > Hadley Wickham's lazyeval package in R is pretty cool in that you can attach an environment to an expression, pass it in and out of functions with various modifications, and then evaluate the expression within the original environment I don't know about R, but to me that sounds entirely doable with closures (and macros will give you a nice syntax for it) > > On Wednesday, July 8, 2015 at 8:31:44 PM UTC-4, Yichao Yu wrote: >> >> On Wed, Jul 8, 2015 at 8:23 PM, Yichao Yu <yyc...@gmail.com> wrote: >> > On Wed, Jul 8, 2015 at 7:48 PM, Brandon Taylor >> > <brandon....@gmail.com> wrote: >> >> Hmm, maybe I'm confused about compilation vs interpretation. Let me >> >> rephrase. Regardless of a how or when statement is evaluated, it must >> have >> >> access at least to its parent environments to successfully resolve a >> symbol. >> >> AFAIK, the only scope you can dynamically add variable to is the >> global scope. (This can be done with the `global` keyword or `eval` >> etc). The compiler figure out the creation/lifetime of all local >> variables (at compile time). Therefore, to access a variable in the >> parent scope: >> >> 1. If it's a global, then it need a runtime lookup/binding (the reason >> global are slow) >> 2. If it's in a parent non-global scope, the compiler can figure out >> how to bind/access it at compile time and no extra (lookup) code at >> runtime is necessary. >> >> >> >> > >> > A julia local variable is basically a variable in C. There's a table >> > at compile time to map between symbols and stack slots (or whereever >> > they are stored) but such a map does not exist at runtime anymore >> > (except for debugging). >> > >> >> >> >> On Wednesday, July 8, 2015 at 7:34:09 PM UTC-4, Brandon Taylor wrote: >> >>> >> >>> They must exist at runtime and at local scope. Evaluating a symbol is >> >>> impossible without a pool of defined symbols in various scopes to >> match it >> >>> to. Unless I'm missing something? >> >>> >> >>> On Wednesday, July 8, 2015 at 7:26:27 PM UTC-4, Jameson wrote: >> >>>> >> >>>> There are global symbol tables for static analysis / reflection, but >> they >> >>>> do not exist at runtime or for the local scope. >> >>>> >> >>>> On Wed, Jul 8, 2015 at 7:06 PM Brandon Taylor <brandon....@gmail.com> >> >> >>>> wrote: >> >>>>> >> >>>>> Surely environments already exist somewhere inside Julia? How else >> could >> >>>>> you keep track of scope? It would be simply a matter of granting >> users >> >>>>> access to them. Symbol tables in a mutable language are by default >> mutable. >> >>>>> It would certainly be possible only give users access to immutable >> >>>>> reifications (which could solve a bunch of problems as is). >> However, it >> >>>>> seems natural to match mutable symbol tables with mutable >> reifications, and >> >>>>> immutable symbol tables with immutable reifications. >> >>>>> >> >>>>> >> >>>>> On Wednesday, July 8, 2015 at 6:50:03 PM UTC-4, Brandon Taylor >> wrote: >> >>>>>> >> >>>>>> I'm not sure I understand... >> >>>>>> >> >>>>>> On Wednesday, July 8, 2015 at 6:24:37 PM UTC-4, John Myles White >> wrote: >> >>>>>>> >> >>>>>>> Reified scope makes static analysis much too hard. Take any >> criticism >> >>>>>>> of mutable state: they all apply to globally mutable symbol >> tables. >> >>>>>>> >> >>>>>>> On Wednesday, July 8, 2015 at 10:26:23 PM UTC+2, Milan >> Bouchet-Valat >> >>>>>>> wrote: >> >>>>>>>> >> >>>>>>>> Le mercredi 08 juillet 2015 à 13:20 -0700, Brandon Taylor a >> écrit : >> >>>>>>>> > All functions. >> >>>>>>>> Well, I don't know of any language which doesn't have scoping >> >>>>>>>> rules... >> >>>>>>>> >> >>>>>>>> Anyway, I didn't say scoping rules are necessarily confusing, I >> was >> >>>>>>>> only referring to R formulas. But according to the examples you >> >>>>>>>> posted, >> >>>>>>>> your question appears to be different. >> >>>>>>>> >> >>>>>>>> >> >
