gc optimizations aren't really the critical issue (although it is a possible side-benefit). the big advantages are enforced type computability (they cannot be accessed in ways that are invisible to inference) and semantic purity (the variables are exactly those you see in the program, plus any spliced in from a macro).
it's not quite right to consider this a compiler phase either, since the identification of a variable's scope is actually done at parse time (just after splicing in the return values from any macro). i agree that macros are confusing when encountering them for the first time. it sometimes helps to view them as functions that take code syntax as arguments and return modified code syntax. that return value is then spliced into the original code exactly as if it was the expression that you typed originally. it is also sometimes also helpful to note that this code transformation happens very early, just after parsing the code, and long before any variables exist or any code has been executed. > On Friday, July 10, 2015 at 4:38:55 AM UTC+2, Brandon Taylor wrote: >> >> 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. >>>>>> >>>>>>>> >>>>>> >>>>>>>> >>>>>> >>>>>
