The current for loop definition is broken with recent evolutions of the language. This is the root cause for issue #4 and many other similar failures. The bottom line is that in the current implementation, the loop variable is unusable.
There was no way to properly inject a name in the body scope, so the loop was really "hacked" into the compiler in the historical Tao3D compiler, and did a number of things that are not as easy to do with the optimizing compiler, like having C++ code modify the values of variables directly.
for N:name in R:[range of discrete] loop Body is
loop_context is
[[N]] : R.type := R.first
LoopVar is loop_context.[[N]]
while LoopVar <= R.last loop
(loop_context) (Body)
++LoopVar
It uses a number of things that are not yet implemented and may need further clarification:
The N:name notation to match a name in the parse tree should work even with the new type system, but was only tested in the old one.
The [range of discrete] notation uses the range and discrete types, neither of which is presently implemented.
The creation of a context like loop_context is only partially supported, and may need rework of the symbol table to fulfil its potential.
The notation LoopVar is loop_context.[[N]] remains to be checked for feasibility. This usage of such an alias declaration would imply to be able to write into the alias. But so far, a lot of the documentation assumes that is can generally be implemented by generating a function. It's unclear if allowing an is definition to be used to write by default is a good idea. Maybe variable LoopVar is loop_context.[[N]] would be useful here.
The (loop_context)(Body) notation injects a scope into Body, and is used to clarify that we are not looking for a loop_context prefix, but for a scope. Things should work without parenthese. Such use of declaration-only bodies as maps is documented but not implemented yet.
The ++LoopVar notation uses a general increment operator for all discrete types that is not implemented yet.
The current
forloop definition is broken with recent evolutions of the language. This is the root cause for issue #4 and many other similar failures. The bottom line is that in the current implementation, the loop variable is unusable.There was no way to properly inject a name in the body scope, so the loop was really "hacked" into the compiler in the historical Tao3D compiler, and did a number of things that are not as easy to do with the optimizing compiler, like having C++ code modify the values of variables directly.
The correct definition is now described in the documentation:
It uses a number of things that are not yet implemented and may need further clarification:
N:namenotation to match a name in the parse tree should work even with the new type system, but was only tested in the old one.[range of discrete]notation uses therangeanddiscretetypes, neither of which is presently implemented.loop_contextis only partially supported, and may need rework of the symbol table to fulfil its potential.LoopVar is loop_context.[[N]]remains to be checked for feasibility. This usage of such an alias declaration would imply to be able to write into the alias. But so far, a lot of the documentation assumes thatiscan generally be implemented by generating a function. It's unclear if allowing anisdefinition to be used to write by default is a good idea. Maybevariable LoopVar is loop_context.[[N]]would be useful here.(loop_context)(Body)notation injects a scope intoBody, and is used to clarify that we are not looking for aloop_contextprefix, but for a scope. Things should work without parenthese. Such use of declaration-only bodies as maps is documented but not implemented yet.++LoopVarnotation uses a general increment operator for all discrete types that is not implemented yet.