On Thu, Jul 9, 2015 at 9:58 AM, Cedric St-Jean <cedric.stj...@gmail.com> wrote: > 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.
Julia already have `macroexpand` so I guess you are talking about editor/REPL feature? > > > > > 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? >>>> >>>>>>>> > > > > > > >
