Talking JIT

[Mike Trader]

>Usually it is sufficient just to print the Basic variables, though it is sometimes informative to inspect the FPU stack.

Exactly right.


I must say I am a big fan of weakly typed languages. http://en.wikipedia.org/wiki/Weak_typing

One of the biggest pains in C++ is casting variables in expressions. A developer should know what to expect when he assigns a DWORD to an INT for example.

[JRS]

I think the idea is to store data as bytes and determine type on use. There are few times I had to use a VAL() with ScriptBasic.

a = "1"
b = 2

PRINT a + b

Would return 3 as the + operator tells SB that we are dealing in numbers with the stored values. After you play with SB for awhile, it all falls into place.

[Charles Pegge]

@Mike,

The Windows32 SDK bears the scars of excessive type specification. Dealing with these makes type matching more complicated but I hope it should be easy enough to lift hunks of C code and headers  and get them to work in Oxygen. When I come across succinct examples from MSDN I will include them with the examples.

To override a type and get the integer value directly you can use "?" as a prefix. Example: ? MyBstr will yield the integer value of the BSTR (a pointer) instead of its string content.

@John.

So far I've got automatic value to string conversion but I have not been so successful going from string to value.
This is largely due to function overloading rules, which allow functions of the same name but different prototypes to be supported. The compiler cannot always make the correct decision which function to use if it is over-enthusiastic about type conversion. Perhaps String-to-number conversion could be attempted as a last resort. This is where things a not so complex for ScriptBasic as it is able to make such decisions at run-time based on the string content.

Charles

[JRS]

So far I've got automatic value to string conversion but ...

So O2h will now allow the following?

a = "1"
b = 2

PRINT a & b

Results: "12"

[Charles Pegge]

Yes exactly.

One further difference: in Oxygen & and + are interchangeable. And when variables are juxtaposed without operators then addition or concatenation is assumed.

Currently these are equivalent:

print a & b
print a + b
print a b

[JRS]

One further difference: in Oxygen & and + are interchangeable.

If that's the case, how does O2h know if your adding the numbers or concatenating as a string?

[Charles Pegge]

If you are assigning to a string then each of the numeric terms will be converted to strings. To ensure that numbers are added together rather than concatenated when strings are present  you need to put them inside an explicit str().

In this example str does not need brackets as it is the final function in the statement.

print "Result "  str 1 2 3

Result 6

I should also clarify thet when & is used with strings it is a concatenator but when applied to numbers it uses the C interpretation and performs a bitwise and

[JRS]

To ensure that numbers are added together rather than concatenated when strings are present  you need to put them inside an explicit str().

In this example str does not need brackets as it is the final function in the statement.

print "Result "  str 1 2 3

Result 6

I would of thought the Result would be "123" not 6 if the STR() forces string concatenation. It just seems backwards to me.

I think the standard + for math and & for concatenation (or bitwise AND) is more readable. I would hate to see O2h get too abstract with simplification and multifunctional operators where you have to guess what is going on.
 

[Charles Pegge]

Unfortunately & has too many meanings for comfort and Oxygen has to conform to C usage as well as accommodate string concat and hex &h numbers in basic

Str always takes a numeric argument so str(1 2 3) or str(1+2+3) will add the numbers as expected and return them in string format.

The programmer has the choice whether to use the abbreviated forms of expression or use the full syntax.
It all depends on getting the clearest most readable code. The resulting binary will be the same.

PS: and or  are still available and I prefer using them to & | && ||