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.
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? >>>>>> > > > > > > > >>>>>> >>>>>
