158 reputation
15
bio website myphysicslab.com
location Seattle, WA
age 58
visits member for 2 years, 5 months
seen Apr 15 '13 at 17:20

Self-employed software engineer, working on open-source software for physics simulations and math exploration. Most fluent in Java, secondarily in C, and some Mathematica. I worked thru an undergrad math degree, and an MBA, and some additional math studies, mostly applied math such as differential equations and vector calculus. I will probably be focusing on Javascript/HTML5 soon.

In the distant past, I worked on early versions of the Macintosh based animation software known as Director. Also a stint at Apple in the early 90's which resulted in the formation of the Apple-IBM joint venture company called Kaleida Labs whose goal was a cross-platform language to support multimedia content delivery, but which was superseded by Java.


Sep
24
awarded  Good Question
Jul
21
awarded  Scholar
Jul
21
awarded  Supporter
Jul
21
comment Local variables in Module leak into the Global context
I'm new to stackexchange and was unaware of how to do this. Thanks for your answers.
Jul
21
accepted Local variables in Module leak into the Global context
Jul
17
awarded  Autobiographer
Jul
16
comment Local variables in Module leak into the Global context
Coming from Java, the Mma contexts seem similar to the Java package mechanism. In Java, you include a name foo from a package, so that you can refer to foo without the full package name like com.baz.bar.foo. In Mma, foo matches the first foo found along the $ContextPath. Just something to get used to.
Jul
16
comment Local variables in Module leak into the Global context
Thx, that’s helpful, especially the bit about the parser generating the symbol. I’m used to Java (or C) where the compiler erases symbols after leaving a scope. Seems like in Mma the compiler/interpreter is always active and never forgets stuff unless you do Remove or such. I imagine this is because of the rule-rewriting nature of Mma. I clearly have a lot to learn to grok Mma.
Jul
16
awarded  Nice Question
Jul
15
comment Local variables in Module leak into the Global context
Thx, but: this "inadvertent creation of symbols that I don't want to exist" means that the whole problem of "shadowing symbols from other packages" is much more likely to happen. So, I would say it could be a problem. Is this summary correct: Module only makes the value (and Attributes) of the symbol "local". The symbol still gets created in the current Context (Global by default), and can therefore shadow any similar name from another Context.
Jul
15
awarded  Student
Jul
13
asked Local variables in Module leak into the Global context