Actually, the mutating case is easier than that, you'd just transform the code to:
function foo(a::Foo) a = Foo.a # do stuff with a Foo.a = a end So long as you don't access Foo.a directly this would work fine. At some point I'm going to make a repository of "Frequently Asked Macros" – just to show off the things you can do with Julia even though you really shouldn't. On Thursday, 12 June 2014 09:21:58 UTC+1, Mike Innes wrote: > > FWIW – putting to one side the question of whether or not this is a good > idea – it would be possible to do this without new language syntax. > However, you'd have to either pass a type hint or be explicit about the > variables you want: > > e.g. > > function tick(state::SvfSinOsc, coef::SvfSinOscCoef) > @with state::SvfSinOsc, coef::SvfSinOsc > # or > @with state (ic1eq, ic2eq) coef (g0, g1) > > lv1 = g0*ic1eq - g1*ic2eq > lv2 = g1*ic1eq + g0*ic2eq > SvfSinOsc(2*v1 - ic1eq, 2*v2 - ic2eq) > end > > This would work in the non-mutating case by calling names() on the type > and making appropriate variable declarations. > > You could then go further and implement > > function tick(state::SvfSinOsc, coef::SvfSinOscCoef) > @with state (ic1eq, ic2eq) coef (g0, g1) begin > > lv1 = g0*ic1eq - g1*ic2eq > lv2 = g1*ic1eq + g0*ic2eq > SvfSinOsc(2*v1 - ic1eq, 2*v2 - ic2eq) > end > end > > Which would walk over the expression, replacing `a` with `Foo.a`. However, > it would be tricky to implement this correctly since you'd have to be aware > of variable scoping within the expression. > > I may implement the non-mutating version of this at some point – it seems > like it could be useful. > > > On Thursday, 12 June 2014 08:21:42 UTC+1, Andrew Simper wrote: >> >> On Thursday, June 12, 2014 2:16:30 PM UTC+8, Andrew Simper wrote: >>> >>> It seems that the local keyword is a bit of a language kludge to me, >>> since it is implied in most cases, apart from stating the new scope in the >>> form of a for loop etc. It would seem more natural and consistent to me to >>> add the local keyword in front of all variables you want to be local in >>> scope, and everyting else is global. This line of reasoning I'm sure has >>> already been argued to death, and obviously having an implicit local was >>> decided to be best. >>> >> >> Having the local keyword like it is makes most sense to me, but I suppose >> it isn't a big deal to me that if you don't explicitly specify local you >> could be referring to something outside the current scope, which is the >> case with for loops. >> >
