Brilliant Mike! This is exactly what I was after, I just want a way to write shorthand names for things within a scope, and the @with macro does just that :) In the example I posted I split the coefficients away from the state so that only the state needs to be returned, I think this is good for efficiency. I'll have a play with @with and see how I go. Passing in names (Typename), isn't a problem, since when a new name is added there is no duplication in doing this.
Keno, sorry for not understanding that this is probably what you meant when you said this would be best off done by using macros, I didn't think of enclosing the entire algorithm in a macro. On Thursday, June 12, 2014 4:21:58 PM UTC+8, 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. >> >
