error handling numbers

[Jim Locker]

This code: number tstnum tstnum = 0.5 results in the error message: Error in statement: tstnum = 0.5 Error: Unexpected characters following r-value expression – ‘.’. Similarly, this code: number nTval if nTval >= 0.5 results in the error message: Error in statement: if nTval >= 0.5 Error: Unexpected characters following conditional expression – ‘.’. This is obviously wrong. I am working around it by establishing a number called nTst then doing nTst = 1/2 and using this result for my comparisons.

[Michael]

Jim wrote:
> This code:
>
> number tstnum
>
> tstnum = 0.5
>
> results in the error message:
>
> Error in statement: tstnum = 0.5 Error: Unexpected characters
> following r-value expression – '.'.
>
> Similarly, this code:
>
> number nTval
>
> if nTval >= 0.5
>
> results in the error message:
>
> Error in statement: if nTval >= 0.5 Error: Unexpected characters
> following conditional expression – '.'.
>
> This is obviously wrong.
>
> I am working around it by establishing a number called nTst then
> doing nTst = 1/2 and using this result for my comparisons.
>

Actually Jim, the real issue is that the compiler does not currently
cope with decimal values in the source code. It is purely a compiler
issue. If you have a value like .5, replace it with 1/2, if you have a
complicated decimal value, stuff it in a string and then use .toval() on
it. I know it is inconvenient, but actually I have had few cases over
the years where I actually needed any kind of decimal constants in the
source code. What is probably more annoying is that you can't use
decimal constants at all, since you can't use anything other than a
literal in the constant statement.

This will eventually be removed, but we have a number of changes we want
to do to the compiler and have been considering a rewrite in
cross-platform C (the current compiler is in SIMPOL), and as such this
issue has been deferred until we do the rewrite.

Ciao, Neil

[Jim Locker]

Interesting. I see why you would choose to write the compiler in simpol,
but I also see some downsides. I guess you do to.

I agree that it is seldom necessary to stick a constant decimal value into
the system (though physical constants like pi, e, q, and h pop to mind
immediately, me being a physicist and all) and I can do it by entering
them as strings then converting, though that is kind of ugly.

I have run across a lot of things that I have labeled signs of immaturity,
but overall the system is working pretty well. The major broken pieces I
have encountered is that edit mode in the combobox (which will KILL me
soon if you don't fix it) and the fact that wxbitmaps don't seem to
respond to z-order in a form.

How much faster would the compiler be, if written in C?

[Michael]

Jim wrote:
> Interesting. I see why you would choose to write the compiler in
> simpol, but I also see some downsides. I guess you do to.

At least it will work anywhere SIMPOL will.

> I agree that it is seldom necessary to stick a constant decimal value
> into the system (though physical constants like pi, e, q, and h pop
> to mind immediately, me being a physicist and all) and I can do it by
> entering them as strings then converting, though that is kind of
> ugly.

True, which is why I want it changed eventually.

> I have run across a lot of things that I have labeled signs of
> immaturity, but overall the system is working pretty well. The major
> broken pieces I have encountered is that edit mode in the combobox
> (which will KILL me soon if you don't fix it) and the fact that
> wxbitmaps don't seem to respond to z-order in a form.

Working on it.

> How much faster would the compiler be, if written in C?

Probably a lot faster. SIMPOL is fast, but some things are inherently
going to be slower.

Ciao, Neil

[Author]

Posts