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