TOPIC:

Hi Antonio,

atlopes wrote: Robert,

I ran the following code against the exact implementation of the BITNOT() functions above.

LOCAL N
LOCAL B

N := 10
B := 0hFFB0

? BITNOT(N)
? BITNOT(B)

The first display statement executes properly and calls the BITNOT(Int) AS Int, the second raises an error: 'XSharp.Error: 'Conversion.Error from USUAL(UNKNOWN) to LONGINT'.

My question is: why is X# trying to convert a USUAL to LONGINT in the first place? If X# knows the type of the underlying value in the second statement ("Q"), and if it's going to convert before calling the function, why not convert to Binary instead?

This happens because the decision about which overload to call happens at compile time, and at that point the compiler does not know which of the two to use, because it does not know what "B" holds, this is determined at runtime.

For both cases it chooses to use the INT overload, although this looks like a bug, the correct behavior would be to report an "ambiguous function call" error, since none of the two functions is more suitable at runtime. This is why Robert suggested to use one "public" interface to the function, because otherwise the compiler will not know which one to use.

Ok, Chris, this was what I needed to know. We must not rely on X#'s decision to convert the USUAL value to a LONGINT, and you'll probably address the issue in the future.

This implementation of BITNOT() now takes USUAL into consideration:

While testing, I noticed another problem with the Binary type. Probably due to its underlying nature, as a function parameter it's being passed by reference instead of value.

Hence, the need for the initialization of the Result variable in BITNOT() function to explicitly use a new value
instead of simply
This will certainly pose more problems elsewhere.

Without this tweaking, this snippet
results in
instead of
as it should.

Hi Antonio,

i modified the usual code from Robert and it gives the same results. Now it doesn´t matter how the var 'B' is declared.

PRIVATE B
LOCAL B
LOCAL B AS BINARY


regards
Karl-Heinz

Hi Anotinio,

I did not say that there is a problem converting a USUAL to INT, this works fine. But of course, if the USUAL does not contain a numeric value, then a conversion to INT will throw an error as expected.

The problem is that when you compile the code, the compiler does not know which one of the many functions to choose, and there is no way to solve that, at least none I can think of, when you use multiple overloads.

Since you now added also a USUAL overload, then the compiler will be choosing this one always, when the argument is untyped, so you can also keep the previous BINARY overload, this will not be called accidentally anymore. I am just not sure if the fact the the compiler currently does pick the USUAL overload among other overloads when passing a USUAL to it should be considered a language feature or "working by coincidence" (that could change in the future), maybe Robert can comment on that.

If this is supposed to always work like that, then I guess it's no harm keeping the non-usual overloads. For existing FoxPro code (where everything is untyped anyway), always the USUAL overload will be called. But for new code, it is indeed handy to be able to call a more suitable overload.

Chris

I did not say that there is a problem converting a USUAL to INT, this works fine.

Nor did I, I hope. Just to clarify, what I questioned was the decision to perform that conversion in particular over others that could be possible. I was ok with you saying

this looks like a bug, the correct behavior would be to report an "ambiguous function call" error, since none of the two functions is more suitable at runtime

I'd prefer to have and keep the overloads for typed arguments. Not only this would reward future code, but it also rewards current VFP typed source code (there is such a thing!).

A final note: I could not reproduce the by reference vs. by value point I mentioned above outside the implementation of BITNOT(). Nevertheless, I think that the behavior is verifiable. Hopefully, it's just something I'm overlooking.

Karl-Heinz,

i modified the usual code from Robert and it gives the same results. Now it doesn´t matter how the var 'B' is declared

As I said to Chris, I would prefer to have all overloads in place. That would reward properly typed code. It would also benefit from the implicit type conversions that the compiler can normally perform, for instance, from float to integer. Your approach requires looking for other numeric types that a USUAL can host, doesn't it?

Hi Antonio,

As I said to Chris, I would prefer to have all overloads in place. That would reward properly typed code. It would also benefit from the implicit type conversions that the compiler can normally perform, for instance, from float to integer. Your approach requires looking for other numeric types that a USUAL can host, doesn't it?

search for "UsualType" in the XSharp help and open the item "UsualType Enumeration". There you´ll find the description of all enum members.

regards
Karl-Heinz

Hi Antonio,

atlopes wrote: Just to clarify, what I questioned was the decision to perform that conversion in particular over others that could be possible.

Understood, but the conversion is not a problem, the problem is that the compiler could not know which overload to call. When you had only those two typed overloads:

FUNCTION BITNOT (n AS INT)
FUNCTION BITNOT (b AS Binary)

and you called it with

BITNOT(any_untyped_var)

then the compiler does not know which one of the two to use. Currently it uses the first one, although there is not really a reason to assume that this one is the intended one (or not). Assuming that the compiler did the right thing by using one of those overloads, then it is also correct to emit code that converts the untyped var value into an INT (the type expected from the function). The conversion is correct, what is wrong is that the compiler did pick one of the two functions, instead of stopping compilation and throwing a compiling error message instead.

atlopes wrote: I'd prefer to have and keep the overloads for typed arguments. Not only this would reward future code, but it also rewards current VFP typed source code (there is such a thing!).

Do you mean typing a LOCAL with "AS"? From what I see, in VFP you can do

LOCAL n AS Integer
n := "Let's put a string in an Integer variable "
? n

and that runs with no errors, so it is not typed really. Or do you mean with a different way?

atlopes wrote: A final note: I could not reproduce the by reference vs. by value point I mentioned above outside the implementation of BITNOT(). Nevertheless, I think that the behavior is verifiable. Hopefully, it's just something I'm overlooking.

No you're right, there's an issue here. The Binary type itself is a STRUCTURE (so it's being passed by value), but it holds its data internally in a byte array (so a reference type) and when you convert the Binary value into a BYTE array in your first local assignment, then the conversion returns that exact internal array. Maybe the best way is to return a new copy of the array instead, will log an incident on that to be looked at.

For now, you can change such code to

LOCAL Source := BinString AS BYTE[]
LOCAL Result := BYTE[]{Source:Length} AS BYTE[]
System.Array.Copy(Source, Result, Source:Length)

although it probably makes more sens to do this same thing in the X# runtime instead.

Chris,

Chris wrote:
No you're right, there's an issue here. The Binary type itself is a STRUCTURE (so it's being passed by value), but it holds its data internally in a byte array (so a reference type) and when you convert the Binary value into a BYTE array in your first local assignment, then the conversion returns that exact internal array. Maybe the best way is to return a new copy of the array instead, will log an incident on that to be looked at.

Given the fact that the binary type is a value type it indeed makes sense to return a copy of the byte array as well (in other words, to make it a really immutable type).

Robert

Chris,

The conversion is correct, what is wrong is that the compiler did pick one of the two functions, instead of stopping compilation and throwing a compiling error message instead.

Exactly this.

[...] so it is not typed really. Or do you mean with a different way?

What is typed is the source code, even if not enforced by the interpreter. A VFP programmer can do almost anything with the variables that he/she declares, including not declaring them at all, but if he/she declares the variables with their types it's certainly not with the intention of trashing the effort.

As for Binary values passed as parameters, thank you for confirming and for your suggestion. Adding an empty 0h to it creates a local copy that can be safely processed.

Robert,

robert wrote: Chris,

Chris wrote:
No you're right, there's an issue here. The Binary type itself is a STRUCTURE (so it's being passed by value), but it holds its data internally in a byte array (so a reference type) and when you convert the Binary value into a BYTE array in your first local assignment, then the conversion returns that exact internal array. Maybe the best way is to return a new copy of the array instead, will log an incident on that to be looked at.

Given the fact that the binary type is a value type it indeed makes sense to return a copy of the byte array as well (in other words, to make it a really immutable type).

Agreed, I made the change. Not sure if also the constructor that accepts a byte array needs to use a cloned buffer as well. If this constructor is supposed to be called only from the compiler emitted code for literals and from within the class code, then there's no point I think.

Btw, I think you accidentally increased the assembly version (not only the file version) of the runtime to 2.8.0.0 instead of 2.6.0.0.

Guys

there are a few options to create a Binary

Now the question: If such a string constructor would be part of the Binary implementation, something like Binary { "House" } works, right ?

regards
Karl-Heinz

Karl Heinz,
Adding such a constructor is no problem at all. In fact I'll map the implicit converter to call the same constructor to keep the logic in one place.
Important to realize is that the mapping between characters and bytes only works for lower ascii characters. Accented characters and characters from other character sets will not map like that. They will be replace with a question mark when translated.

Robert

Hi Robert,

yes, i´m aware of the problems. If e.g. Chris creates a byte array with some special greece chars included i won´t be able to see on my machine the correct string presentation if i simply use RuntimeState.WinEncoding:GetString( bArr).

i asked about the string constructor because it´s possible to do this:

regards
Karl-Heinz

Hi Robert,

forgot to mention, but maybe it´s already known ?.

What´s missing is the IsBinary() function.

regards
Karl-Heinz

Karl-Heinz ,

I have added that function as well.

Robert

Going back to Chris's question, here is a list of common VFP functions that I think would signify an advancement if implemented from scratch or recreated to match VFP's behavior closer:

• EMPTY() and EVL() (I'm not forgetting this, Matt)
• ISNULL()
• ALINES()
• TRANSFORM() (verify formats) and TTOC()
• TEXTMERGE()
• STREXTRACT()
• XMLTOCURSOR() and CURSORTOXML()
• AERROR(), at least to support SQL* functions
• GETFILE(), PUTFILE() and LOCFILE()

Because of how this thread evolved, I worked on the BIT* functions. I will propose them in a separate thread.