On Mon, Jul 20, 2015 at 9:41 PM, Brandon Taylor <brandon.taylor...@gmail.com> wrote: > Dicts seem to work pretty well for this kind of thing. >
For storage, maybe. > > 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. You cannot assign to module. You need `eval` >> >> 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. >>> >>>>>>> >>>>>>>> >>> >>>>>>> >>>>>>>>
