Compiler Bug

Started by Don Kinzer April 24, 2004
One of these generates a compile error while the other is OK.

Dim i as Integer

i = -3 + 5
i = 5 + -3

Both should compile error free.



The fix is: adding brackets and then it compiles just fine
i= 5 + (-3) rr

BasicX is not VB, but it will do. --- In , "Don Kinzer" <dkinzer@e...> wrote:
> One of these generates a compile error while the other is OK.
>
> Dim i as Integer
>
> i = -3 + 5
> i = 5 + -3
>
> Both should compile error free.





--- In , "raunig2003" <raunig2003@y...> wrote:
> The fix is: adding brackets and then it compiles just fine
> i= 5 + (-3)

Actually the fix is to modify the parser in the compiler to recognize
a syntactically correct expression. The workaround that you offered
is handy to remember until such time as it is fixed.

There are quite a few annoyances in the compiler including the goofy
requirement to add a trailing ampersand on large hex values. I don't
mean to be insulting here but, really! Why not just fix it in the
compiler instead of making the users jump through hoops?

I guess I need to get some sleep. I'm feeling crotchety.


From: Don Kinzer <>

> In , raunig2003 <raunig2003@y...>
> wrote:
>
>> The fix is: adding brackets and then it compiles
>> just fine
>> i= 5 + (-3)
>
> Actually the fix is to modify the parser in the
> compiler to recognize a syntactically correct
> expression.

Well, if somebody can tell me what is syntactically correct for a
notoriously nonstandard language like Basic, I'm all ears.

The expression parser for BasicX was originally written from
Pascal syntax diagrams. In this particular case, Pascal is
apparently more restrictive than VB. Why, I don't know, but I'd
guess the reason is to make the expression less ambiguous and
easier to read. But that's just a guess, and we didn't feel it
was worth the effort to change the semantics.

> There are quite a few annoyances in the compiler
> including the goofy requirement to add a trailing
> ampersand on large hex values. [...]

Try this code in either BasicX or VB:

Public Sub Main()

Dim L As Long

L = &HFFFF&
Debug.Print "L = "; CStr(L)

L = &HFFFF
Debug.Print "L = "; CStr(L)

End Sub

In the first line, L is 65535. In the second line, L is -1.

If you think this is OK, you can turn off strict syntax checking,
and the BasicX compiler will allow it, just like VB will allow
it.

I personally think this is a horrendously, stupendously bad idea.
But that's just me.

-- Frank Manning
-- NetMedia, Inc.



Another bug is that the compiler does not allow the order of the
arguments the way a user desires for certain types. There is no
reason given in the docs.

Allowed: Public Function InStr(Byval s1 As String, Byval s2 As
String, ByVal nStart As Byte ) As Byte

Not allowed: Public Function InStr(ByVal nStart As Byte, Byval s1 As
String, Byval s2 As String ) As Byte

rr

--- In , "Frank Manning" <fmanning@n...> wrote:
> From: Don Kinzer <dkinzer@e...>
>
> > In , raunig2003 <raunig2003@y...>
> > wrote:
> >
> >> The fix is: adding brackets and then it compiles
> >> just fine
> >> i= 5 + (-3)
> >
> > Actually the fix is to modify the parser in the
> > compiler to recognize a syntactically correct
> > expression.
>
> Well, if somebody can tell me what is syntactically correct for a
> notoriously nonstandard language like Basic, I'm all ears.
>
> The expression parser for BasicX was originally written from
> Pascal syntax diagrams. In this particular case, Pascal is
> apparently more restrictive than VB. Why, I don't know, but I'd
> guess the reason is to make the expression less ambiguous and
> easier to read. But that's just a guess, and we didn't feel it
> was worth the effort to change the semantics.
>
> > There are quite a few annoyances in the compiler
> > including the goofy requirement to add a trailing
> > ampersand on large hex values. [...]
>
> Try this code in either BasicX or VB:
>
> Public Sub Main()
>
> Dim L As Long
>
> L = &HFFFF&
> Debug.Print "L = "; CStr(L)
>
> L = &HFFFF
> Debug.Print "L = "; CStr(L)
>
> End Sub
>
> In the first line, L is 65535. In the second line, L is -1.
>
> If you think this is OK, you can turn off strict syntax checking,
> and the BasicX compiler will allow it, just like VB will allow
> it.
>
> I personally think this is a horrendously, stupendously bad idea.
> But that's just me.
>
> -- Frank Manning
> -- NetMedia, Inc.




--- In , "Frank Manning" <fmanning@n...> wrote:
> Well, if somebody can tell me what is syntactically correct for a
> notoriously nonstandard language like Basic, I'm all ears.

Perhaps I assume too much. The documentation makes frequent mention
of the intent to be VB-compatible. There are numerous descriptions
of instances where the compatibility is more or less lacking. So, in
the absence of any specific statement to the contrary, my assumption
was that BasicX should follow the VB standard, otherwise it's a bug.

The two examples that I gave compile without error on VB6. Now that
I've said that, I realize that I may have made another invalid
assumption. Exactly which version VB does BasicX attempt to be
compatible with? I know that Microsoft has made many changes in
VB .Net and that that's almost certainly not the standard by which to
measure BasicX. That's why I chose VB6 as the presumptive standard.
Perhaps I erred.



From: raunig2003 <>

> Another bug is that the compiler does not allow the
> order of the arguments the way a user desires for
> certain types. There is no reason given in the docs.
> [...]
> Not allowed:
> Public Function InStr(ByVal nStart As Byte,
> Byval s1 As String, Byval s2 As String ) As Byte

Yes, this is a bug. If you pass one or more strings by value, the
strings have to be first in the parameter list. The reason has to
do with the way strings are pushed on the stack.

It's not unusual for compilers to have various restrictions like
this for low-level code generation, and the usual fix is for the
compiler to silently rearrange parameters.

This hasn't been done yet in BasicX. It's on our list of bugs to
fix.

-- Frank Manning
-- NetMedia, Inc.


From: Don Kinzer <>

> In , "Frank Manning"
> <fmanning@n...> wrote:
>>
>> Well, if somebody can tell me what is syntactically
>> correct for a notoriously nonstandard language like
>> Basic, I'm all ears.
>
> Perhaps I assume too much. The documentation makes
> frequent mention of the intent to be VB-compatible.

Good point. I used a poor choice of words.

> There are numerous descriptions of instances where
> the compatibility is more or less lacking. So, in
> the absence of any specific statement to the
> contrary, my assumption was that BasicX should
> follow the VB standard, otherwise it's a bug.

BasicX is advertised as subset-compatible with VB. For this
expression:

i = 5 + - 3

if the expression won't compile in BasicX, but will compile if
you add parentheses, I'd classify that as a subset compatibility
issue rather than a bug.

> The two examples that I gave compile without error on
> VB6. Now that I've said that, I realize that I may
> have made another invalid assumption. Exactly which
> version VB does BasicX attempt to be compatible with?
> [...]

BasicX is subset-compatible with both VB6 and VB.NET.

-- Frank Manning
-- NetMedia, Inc.


> ... Exactly which version VB does BasicX attempt to be compatible
with?

Personally, I liked the VB compatibility claim when I encountered the
BX-24 because I was pretty proficient in VB4+, after struggling with
Basic Stamp's abomination (my opinion; no arguments, please), but it
matters little to me today if VB is or is not perfectly Basic-X
compatible. For a time I used VB6 as a source code editor, but I no
longer do so I am not exposed to these apparent discrepancies.

I use VB6 for PC-based apps frequently and I use Basic-X for BX-24 apps
frequently and I haven't, so far, confused the two; not one of my BX-24
apps runs on a PC, nor vv. [That said, in it's defense I admit it was
convenient to be able to build a huge trig one-liner on a PC before
trying it on a BX-24, where it worked, untouched.]

As a general concern, though, I wonder, Don, if your VB-incompatibility
issue isn't idealistic and has little practical importance beyond
indoctrination. Do you routinely code and compile your BX-24 projects
in VB6? If you do, I understand your dislike of false (or overlooked)
syntax errors but, if you don't, why does it matter after getting on
your Basic-X feet more quickly? Is it philosophically important to you,
or is it a matter of Netmedia dishonor that a statement of compatibility
isn't pure truth? Disregarding Microsoft's dishonor, what claim of its
is pure truth? Tom
Tom Becker
--... ...--
www.RighTime.com
The RighTime Clock Company, Inc., Cape Coral, Florida USA
+1239 540 5700



--- In , "Tom Becker" <gtbecker@r...> wrote:
> [...] Is it philosophically important to you, or is it a
> matter of Netmedia dishonor that a statement of compatibility
> isn't pure truth? [...]

I think that it's a matter of unmet expectation, perhaps
idealistically held.

'nuff said.