Unless it did, in which case, I'm just uneducated.
On Thursday, July 9, 2015 at 6:31:03 PM UTC-4, Brandon Taylor wrote: > > 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> >> 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? >>>> >>>>>>>> > > > > > > > >>>> >>> >>
