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 <javascript:>> 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. > >>>>>>> >>>>>>>> > >>>>>>> >>>>>>>> >
