Although that would probably require nested dicts. Each would have a parent dict, and if a lookup isn't found in the current dict, the parent dict would be searched.
On Tuesday, July 21, 2015 at 9:53:50 AM UTC+8, Brandon Taylor wrote: > > I should be possible to preprocess code such that everything is put into a > dict based on the name of enclosing function (and global variables will > just go into a dict called global). > > On Tuesday, July 21, 2015 at 9:42:00 AM UTC+8, Brandon Taylor wrote: >> >> Dicts seem to work pretty well for this kind of thing. >> >> On Tuesday, July 21, 2015 at 9:38:36 AM UTC+8, Brandon Taylor wrote: >>> >>> I'm getting a cannot assign variables in other modules error. >>> >>> On Tuesday, July 21, 2015 at 6:39:44 AM UTC+8, Yichao Yu wrote: >>>> >>>> On Mon, Jul 20, 2015 at 6:35 PM, Brandon Taylor >>>> <brandon....@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. >>>> >>>>>>> >>>>>>>> >>>> >>>>>>> >>>>>>>> >>>> >>>
