Ok, a thought, Julia has an inbuilt idea of a module. Would it be possible to hijack this functionality to provide pseudo-environments? That is, never referring to anything that is not already in an explicit module? And also, have a data-frame simply be a module?
On Friday, July 10, 2015 at 11:31:36 PM UTC+8, Brandon Taylor wrote: > > I don't know if you came across the vignette? > http://cran.r-project.org/web/packages/lazyeval/vignettes/lazyeval.html ? > dplyr uses lazyeval extensively, see > http://cran.r-project.org/web/packages/dplyr/vignettes/nse.html . The > cool thing about being able to incorporate this kind of thing in Julia > would be being able to use the self-reflection capabilities. > > On Friday, July 10, 2015 at 10:57:16 AM UTC-4, Cedric St-Jean wrote: >> >> >> >> On Thursday, July 9, 2015 at 10:35:30 PM UTC-4, Brandon Taylor wrote: >>> >>> To walk back in time, you could say something like: compile this like >>> this was is in line 8. Or compile this like this was in line 5. It seems >>> like Julia already has some of this functionality in macros. Internal >>> variables are compiled as if they were in local scope. But escaped >>> expressions are compiled as if they were in global scope. >>> >> >> Could you provide context or a real-world use? I've looked at the >> lazyeval package, and I'm not entirely sure what it does. Does it provide >> lazy evaluation for R? That's easy to achieve in Julia (well, sorta). >> Instead of >> >> d = determinant(matrix) >> .... >> u = 2 * d >> >> you can write >> >> d = ()->determinant(matrix) >> .... >> u = 2 * d() # determinant is evaluated on use, in the context where it >> was originally defined >> >> With macros this can turn into >> >> d = lazy(determinant(matrix)) >> >> which looks nicer (and also can avoid computing the determinant twice if >> d() is called twice). >> >> Cédric >> >> >>> >>> On Thursday, July 9, 2015 at 9:11:05 PM UTC-4, Cedric St-Jean wrote: >>>> >>>> >>>> >>>> On Thursday, July 9, 2015 at 4:14:32 PM UTC-4, Brandon Taylor 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, >>>>> >>>> >>>> Yes, more or less. >>>> >>>> >>>>> >>>>> 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. >>>>> >>>> >>>> Could you expand on what you're thinking of? >>>> >>>> This kind of compile-time environment could conceivably be exposed to >>>> macros. Common Lisp had proposals along that line ( >>>> https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node102.html) but as >>>> far as I can tell, it was too complicated and not useful enough, so it was >>>> axed/neutered at some point in the standardization process. >>>> >>>> > 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 >>>> >>>> I don't know about R, but to me that sounds entirely doable with >>>> closures (and macros will give you a nice syntax for it) >>>> >>>> >>>>> >>>>> 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. >>>>>> >>>>>>>> >>>>>> >>>>>>>> >>>>>> >>>>>
