https://en.wikipedia.org/wiki/Variable_(computer_science)#Scope_and_extent
On Thu, Jul 9, 2015 at 4:14 PM, Brandon Taylor <brandon.taylor...@gmail.com> 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, > > 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. > > > 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. >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> Regards >> >>>>>>>> >> >>>>>>>> > On Wednesday, July 8, 2015 at 4:18:09 PM UTC-4, Milan >> Bouchet-Valat >> >>>>>>>> > wrote: >> >>>>>>>> > > Le mercredi 08 juillet 2015 à 12:57 -0700, Brandon Taylor a >> écrit >> >>>>>>>> > > : >> >>>>>>>> > > >> >>>>>>>> > > > If scoping rules are too complicated and cause confusion, >> why >> >>>>>>>> > > > are >> >>>>>>>> > > >> >>>>>>>> > > > they built into the base implementation of function? >> >>>>>>>> > > What do you mean? Which function? >> >>>>>>>> > > >> >>>>>>>> > > > On Wednesday, July 8, 2015 at 3:48:52 PM UTC-4, Milan >> Bouchet >> >>>>>>>> > > -Valat >> >>>>>>>> > > > wrote: >> >>>>>>>> > > > > Le mercredi 08 juillet 2015 à 12:34 -0700, Brandon >> Taylor a >> >>>>>>>> > > écrit : >> >>>>>>>> > > > > >> >>>>>>>> > > > > > I was aware of those packages (though I hadn't read >> the >> >>>>>>>> > > > > discussions >> >>>>>>>> > > > > > referenced). Macros are great but they are incredibly >> >>>>>>>> > > difficult >> >>>>>>>> > > > > to >> >>>>>>>> > > > > > reason with concerning issues of scope (at least for >> me). >> >>>>>>>> > > > > Deifying >> >>>>>>>> > > > > > environments could solve all of these issues (and so >> much >> >>>>>>>> > > more) >> >>>>>>>> > > > > in >> >>>>>>>> > > > > > one fell swoop. >> >>>>>>>> > > > > On the contrary, I think well-designed macros can be >> much >> >>>>>>>> > > easier to >> >>>>>>>> > > > > >> >>>>>>>> > > > > think about than environments in R. If the macro takes a >> >>>>>>>> > > DataFrame >> >>>>>>>> > > > > object and an expression, there's no ambiguity about >> what the >> >>>>>>>> > > scope >> >>>>>>>> > > > > is. >> >>>>>>>> > > > > This is even better if variables that should be found in >> the >> >>>>>>>> > > data >> >>>>>>>> > > > > frame >> >>>>>>>> > > > > are passed as symbols, like :var, while standard >> variables >> >>>>>>>> > > > > are >> >>>>>>>> > > > > specified as usual. >> >>>>>>>> > > > > >> >>>>>>>> > > > > On the other hand, I find R formulas too flexible and >> complex >> >>>>>>>> > > to >> >>>>>>>> > > > > reason >> >>>>>>>> > > > > about. You never know whether an object will be found in >> the >> >>>>>>>> > > > > formula's >> >>>>>>>> > > > > environment, in one of the parent environments of the >> >>>>>>>> > > > > function/package >> >>>>>>>> > > > > you called, in your function, or in the global >> environment. >> >>>>>>>> > > > > >> >>>>>>>> > > > > >> >>>>>>>> > > > > Regards >> >>>>>>>> > > > > >> >>>>>>>> > > > > > On Wednesday, July 8, 2015 at 3:20:00 PM UTC-4, David >> Gold >> >>>>>>>> > > wrote: >> >>>>>>>> > > > > >> >>>>>>>> > > > > > > Some of these issues have been thought about fairly >> >>>>>>>> > > extensively >> >>>>>>>> > > > > by >> >>>>>>>> > > > > > > the stats community in particular, precisely on >> account >> >>>>>>>> > > > > > > of >> >>>>>>>> > > the >> >>>>>>>> > > > > use >> >>>>>>>> > > > > > > cases you cite: >> >>>>>>>> > > > > > > >> >>>>>>>> > > > > > > https://github.com/JuliaStats/DataFrames.jl/pull/472 >> >>>>>>>> > > > > > > >> https://github.com/JuliaStats/DataFrames.jl/issues/504 >> >>>>>>>> > > > > > > >> >>>>>>>> > > > > > > I think that the matter is still very much an open >> >>>>>>>> > > question. I >> >>>>>>>> > > > > have >> >>>>>>>> > > > > > > no sense that anything is going to be added to Base >> Julia >> >>>>>>>> > > > > itself. >> >>>>>>>> > > > > > > Currently, the best way (that I know of, anyway) to >> >>>>>>>> > > > > > > achieve >> >>>>>>>> > > the >> >>>>>>>> > > > > >> >>>>>>>> > > > > > > delayed evaluation effect is via the use of macros. >> See >> >>>>>>>> > > > > > > for >> >>>>>>>> > > >> >>>>>>>> > > > > > > instance: >> >>>>>>>> > > > > > > >> >>>>>>>> > > > > > > https://github.com/JuliaStats/DataFramesMeta.jl >> >>>>>>>> > > > > > > https://github.com/one-more-minute/Lazy.jl >> >>>>>>>> > > > > > > >> >>>>>>>> > > > > > > I'm hope somebody else will be able to pop in an >> give a >> >>>>>>>> > > more >> >>>>>>>> > > > > > > thorough answer, but the above may at least be a >> place to >> >>>>>>>> > > > > start. >> >>>>>>>> > > > > > > >> >>>>>>>> > > > > > > On Wednesday, July 8, 2015 at 2:03:45 PM UTC-4, >> Brandon >> >>>>>>>> > > Taylor >> >>>>>>>> > > > > > > wrote: >> >>>>>>>> > > > > > > > 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 (or any >> >>>>>>>> > > > > > > > other >> >>>>>>>> > > > > > > > environment that you choose). R in general has the >> >>>>>>>> > > functions >> >>>>>>>> > > > > like >> >>>>>>>> > > > > > > > list2env and list(environment()) that allow one to >> >>>>>>>> > > convert an >> >>>>>>>> > > > > >> >>>>>>>> > > > > > > > environment into a list and back again (list being >> the >> >>>>>>>> > > > > > > > R >> >>>>>>>> > > > > > > > equivalent of a Dict). Are there any plans to add >> these >> >>>>>>>> > > kind >> >>>>>>>> > > > > of >> >>>>>>>> > > > > > > > features to Julia? >> >>>>>>>> > > > > > > > >> >
