Is the issue garbage collection? That because by choosing variables dynamically from a symbol table, you don't know which variables are going to be used, so you don't know which data can be deleted early?
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. Or maybe not, macros still > confuse me. > > 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. >>>> >>>>>>>> >>>> >>>>>>>> >>>> >>>
