HGS loops don't behave as expected

[jpm86]

while and repeat loops should behave more in line with expectations carries from other procedural languages. In particular, it should be possible to declare a new variable within the scope introduced by the loop body. This is currently not possible because the Contexts built for their inner scopes are re-used, and the interpreter sees a redeclaration upon the second iteration.

P.S. break and continue would also be really nice to have.

P.P.S. I threw together a simple implementation for all of this if you're interested.

[hneemann]

I'm surprised that someone would delve so deeply into the hgs language, which was originally intended only for hdl templates and then rather accidentally reused for generic circuits. 😄
Do you use the languages for hdl templates or to create generic circuits?

The too wide scope in the repeat and while body is rather a bug and very easy to fix. Break and continue are more difficult to add, and since I'm not a fan of either, I'd rather avoid the added complexity.

[jpm86]

I'm surprised that someone would delve so deeply into the hgs language, which was originally intended only for hdl templates and then rather accidentally reused for generic circuits. 😄

What can I say, I'm an irredeemable tinkerer :)

Do you use the languages for hdl templates or to create generic circuits?

My use case is generic circuits (though I've poked around in the hdl templates in the code base while exploring integrating with custom executables).

Once I got used to the scripting language, I found it useful not just for parameterized components and building out repetitive structures, but also for pre-computing large and/or complex lookup tables. (Or really any combination of those concerns).

The too wide scope in the repeat and while body is rather a bug and very easy to fix. Break and continue are more difficult to add, and since I'm not a fan of either, I'd rather avoid the added complexity.

I'll agree to disagree about the utility of break and continue, but in terms of implementation complexity, my approach is very lightweight (it uses the same basic approach as function return, except that it doesn't need to return anything). Now that I think about it, though, I used a wrapper around the loop-body statement to make sure break and continue couldn't be executed elsewhere, but I suspect I'd have to add a bit more machinery to ensure they don't escape the enclosing function scope.

I don't expect the final solution would be significantly more complex, though, and I'm more than happy to push forward on it and at least share my work with you if there's any chance you're not dead-set on keeping those keywords out of the language.