Environments are very natural in interpreted languages, but I'm not aware of any fully-compiled language that supports them because they'd be a major headache. I agree that macro behavior can be hard to predict. In Common Lisp with Emacs, one can macroexpand any expression anywhere with one keypress, and it is incredibly useful for figuring things out. I'm sure that Julia will eventually get that functionality, it's several orders of magnitude easier than supporting environments.
On Wednesday, July 8, 2015 at 9:51:16 PM UTC-4, Brandon Taylor wrote: > > Edit: Hmm, so that means that any implementation of environments would > have to be handled in two separate ways: one by the compiler for non-global > scope, and one in run time for the special global system?] > > > On Wednesday, July 8, 2015 at 9:49:50 PM UTC-4, Brandon Taylor wrote: >> >> Hmm, so that means that any implementation of environments would have to >> be handled in to separate ways: one by the compiler for non-global scope, >> and one in run time using a second for the special global system?] >> >> >> 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? >>> >>>>>>>> > > > > > > > >>> >>
