Ok, that was an interesting article, but it didn't really answer my question.
On Thursday, July 9, 2015 at 4:20:45 PM UTC-4, Isaiah wrote: > > https://en.wikipedia.org/wiki/Variable_(computer_science)#Scope_and_extent > > On Thu, Jul 9, 2015 at 4:14 PM, Brandon Taylor <brandon....@gmail.com > <javascript:>> 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? >>> >>>>>>>> > > > > > > > >>> >> >
