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 <[email protected]> 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? >>>> > > > > > > > >>>> >>>
