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