Spurious parameter error

[RacingDog]

This is an amusing little run time bug. The code shows two uses of a sub call.
The first is executed, the second identical call causes an error saying that only regular variables can be passed.

Hmm. That would be same parameter which was seen as a regular variable in the first call then? Ho Ho!

Even if there is some restriction on where such subs may be used, which there shouldn't be (an expression is an expression is an expression), that would be completely the wrong error report.

[Erel]

Thank you for reporting it. It will be fixed in the next update. The problem lies with the call being inside a condition expression.

[RacingDog]

These things sometimes filter through the brain slowly and eventually lead to further questions. Nothing but curiosity if you can spare me a second. But is a compiler/compiler (or parser generator as some have it) used in producing this language? If so, which one?

[Erel]

The parsing is done manually. At the time of writing the first version, back in 2005, I wasn't familiar with any stable .Net parser generator.

[RacingDog]

That's a shame. No wonder some bits are tricky to change.

[RacingDog]

Eventually it occured to me to wonder why a parser generator needs to know anything about .net. It doesn't need to know about it to run on windows, and all it is producing is, for example C# code, mostly by user written semantic actions or AST scanners, where the user can put as much .net awareness as he wants, because it isn't actually used until the generated code is compiled and/or linked into the target .net project. It's a text processor producing different text, so I'm not sure how that needs to be .net aware, it's just text.

[Erel]

I meant that I'm not familiar with any parser generator like bison or flex that runs on .Net CF.

[RacingDog]

Ah, right. But would the need to? Having .Net doesn't stop native mode apps from running Oh well, never mind, I just like using them, so I'm predjudiced,