On Mon, Jul 20, 2015 at 6:35 PM, Brandon Taylor <brandon.taylor...@gmail.com> wrote: > 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?
I think this would in principle works. A module is basically what global scope means so all the performance concern applies. > > > 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. >>>>>>> >>>>>>>> >>>>>>> >>>>>>>>
