[Compiler] Variable "has no value" when compiled (interpreted works)

[SkySpiral7]

[Compiler] Variable "has no value" when compiled (interpreted works)

[dockimbel]

After a short analysis, I am not still not sure if it is a compiler limitation (most probably) or just a bug.

The core issue is that switch (like most other control flow functions when compiled) requires a static block as second argument. If you provide a dynamic one (like here generating it with reduce), you are on your own, as the compiler cannot statically analyze what switch will get as second argument anymore. In such case, it may work without issue, or not, depending on what you provide.

I will do a more in-depth investigation in the next days to get to the bottom of it, though, in the meantime, you can use at least two workarounds:

1. Set explicitly deltaStream value when cloning the object:

deltaItr: make deltaIterator [deltaStream: 100]

2. Force the binding of the reduce argument block to the local object:

switch deltaStream bind reduce [...] self

Anyway, I am working on deprecating the high-level compiler partially (or completely), so that all provided Red code will be directed to the interpreter, getting rid of those problematic static/dynamic combos edge cases for the compiler. Such cases can be solved but the increase in complexity in the compiler internals is just not worth the effort. They are better (cleaner, faster, shorter) ways.

[SkySpiral7]

It doesn't make sense to me that switch takes a static block, I expected it to bind to the self by default (which would match interpreted). Your work around #2 does work however #1 doesn't: deltaItr: make deltaIterator [deltaStream: 64] has the same "no value" error. The reason the value 100 didn't fail is because the switch statement doesn't match and therefore the deltaStream value is not accessed.

I'm guessing by "high-level compiler" you mean compiling ahead of time instead of JIT. Being able to do redc -e -r is pretty fundamental to distribution but AOT vs JIT doesn't make much difference. I wouldn't mind redc -c being removed and -e being the new default. AOT would be better but maybe it contradicts Red design at a fundamental level such that it would never be possible (or maybe just impractical).

[dockimbel]

After a deeper analysis, I confirm that it is a compiler limitation: the deltaStream word in the reduce argument block is stored (along with that block) in redbin format with a binding to an empty context, as the compiler in the above case compiles the objects entirely into code, so that the compiled context and the one stored in redbin format are not linked together. The result is that the inner deltaStream is pulling its value from an empty context in redbin format where all the fields are unset.

It doesn't make sense to me that switch takes a static block

I should have used "literal" instead of "static" there to avoid misunderstanding.

The reason the value 100 didn't fail is because the switch statement doesn't match and therefore the deltaStream value is not accessed.

You're right, I've missed that, sorry.

I'm guessing by "high-level compiler" you mean compiling ahead of time instead of JIT

I meant the Red to Red/System compiler which is currently an AOT one. In the future, we will have a JIT one, which is a much better fit for Red semantics.

Being able to do redc -e -r is pretty fundamental to distribution

We're keeping that of course.

AOT would be better but maybe it contradicts Red design at a fundamental level such that it would never be possible (or maybe just impractical).

That's exactly right.

[dockimbel]

I will leave that ticket open with the "wontfix" status until we drop the Red compiler. Once that done, we'll close all the "type.compiler" tickets all together.