xsharp.eu

Posted: **Wed Oct 23, 2019 7:44 pm**

I notice that outside of a function, a PUBLIC variable which is given a value is declared like this: PUBLIC iAccumulatorVariable = 1

But within a function, a LOCAL can be declared like this: LOCAL x = 1 as int. A similar PUBLIC declaration (PUBLIC iAccumulatorVariable = 1 as int) gives an error. I'm curious as to why the declaration of a LOCAL versus a PUBLIC variable have a different syntax.

Posted: **Wed Oct 23, 2019 8:39 pm**

Hi Kevin,

According to the Visual FoxPro documentation, PUBLIC statement may or not have AS <type>.
So, I think this is a compiler bug.

Ref: https://docs.microsoft.com/en-us/previo ... 3dvs.71%29

Jamal

Posted: **Wed Oct 23, 2019 8:52 pm**

If I understand the help entry correctly, the AS clause is being ignored by the VFP compiler, it is only used by the editor to provide member completion. PUBLICs, MEMVARs etc do not have a type in their declaration, because due to their semantics (can be created and destroyed at will during runtime), the compiler cannot do any compile time checking on their usage.

LOCALs can be completely checked at compile time for their usage,but still, it is also possible to have them untyped by omitting their AS clause.

Posted: **Wed Oct 23, 2019 9:08 pm**

Visual Foxpro doesn't require variable declaration, but it allows it. I always declare and initialize my variables as LOCAL whenever possible so as not to interfere with previously existing variables, and also because a variable which is declared as a local object can use intellisense completion. But a variable declared as a type in VFP isn't really that type. For example, a variable declared as an integer is not internally an integer as you can tell if you pass it to an external routine. I wonder whether xsharp should actually strongly type variables when they are declared as something. That would actually be helpful in a lot of ways; not for existing code but for new code. Maybe that could be a compiler switch. BTW, the ability to declare and give a value to a variable on the same line is something I really like, even though it's not valid VFP syntax.

Posted: **Wed Oct 23, 2019 9:18 pm**

Kevin Clark wrote:.. a variable declared as an integer is not internally an integer as you can tell if you pass it to an external routine.

Out of curiosity: would you explain this a bit more? If "AS INT" doesn't ensure the var "is" an int, what is it then, and why?

I wonder whether xsharp should actually strongly type variables when they are declared as something.

Well, at least in Core, VO and VN it does

Posted: **Wed Oct 23, 2019 9:32 pm**

Kevin,
We will add support for the AS Type clause in X# too. But it will be ignored just like in VFP.
PUBLIC variables are stored in a dictionary at runtime with a name and a (USUAL) value.
I am only not sure if we should generate a compiler warning that the AS Type clause will be ignored.
What do you think: should we generate a warning (since the same clause for a LOCAL DOES enforce the type).

Robert

Posted: **Wed Oct 23, 2019 9:39 pm**

Kevin,

Kevin Clark wrote:Visual Foxpro doesn't require variable declaration, but it allows it. I always declare and initialize my variables as LOCAL whenever possible so as not to interfere with previously existing variables, and also because a variable which is declared as a local object can use intellisense completion. But a variable declared as a type in VFP isn't really that type. For example, a variable declared as an integer is not internally an integer as you can tell if you pass it to an external routine..

It's worse then that. We recently discovered that you can use a variable name for a local variable in the Type() function and this will work in VFP. So the variable (its name and value) is visible outside of the scope of the function / method where it is defined.
This seems to indicate that VFP implements LOCAL variables just like dynamic memory variables (PRIVATES and PUBLICS) and has only added a flag to them telling the runtime that they should not be visible outside of the function/method where they are defined, and apparently the Type() function ignores this flag.

X# generates REAL local variables, They are scoped to the function/method only, or if you declare a local inside a block, such as a FOR block then that local is only visible inside that block. That is how most development languages do it.
So in X# the Type() function will not be able to tell you that a local variable exists or what its value is. Unless we change the compiler and runtime to also do the same kind of tricks that FoxPro does, but I am not sure if we should want to do that.

Robert

Posted: **Wed Oct 23, 2019 10:44 pm**

Hi Kevin,

Kevin Clark wrote:Visual Foxpro doesn't require variable declaration, but it allows it.

Yes because it actually ignores the AS Type. X# not, because even if you LOCAL i, X# will add "AS USUAL".

I always declare and initialize my variables as LOCAL

Very good style. X# by default in the other dialects force you to do it. So less work for you to make your VFP code work in X#.

I wonder whether xsharp should actually strongly type variables when they are declared as something. That would actually be helpful in a lot of ways; not for existing code but for new code.

Well if X# finds AS Type it will immediately strongly type that variable...

BTW, the ability to declare and give a value to a variable on the same line is something I really like, even though it's not valid VFP syntax.

Yes and you can even do:

Code: Select all

local x := y := z := 0 as int

The beauty of X#. The Core is even available when you in VFP syntax mode... and you can mix and match it.

Posted: **Thu Oct 24, 2019 10:41 am**

Robert van der Hulst wrote: It's worse then that. We recently discovered that you can use a variable name for a local variable in the Type() function and this will work in VFP. So the variable (its name and value) is visible outside of the scope of the function / method where it is defined.
This seems to indicate that VFP implements LOCAL variables just like dynamic memory variables (PRIVATES and PUBLICS) and has only added a flag to them telling the runtime that they should not be visible outside of the function/method where they are defined, and apparently the Type() function ignores this flag.

Robert,
I can follow your reasoning and quesy feeling about "atypical function" behaviour of Type().
But the stepsister of Type(), Eval() does it in spades:

Code: Select all

CLEAR
LOCAL lcLocal
lcLocal = "LOCAL, dammit"
LOCAL lcPlus 
lcPlus = " + "
LOCAL lcMore 
lcMore = " reaches more Names of previous scope"
LOCAL lcLeveled 
lcLeveled = "lclocal"
? EVALUATE("lcLocal  + lcPlus + lcMore")
? TRANSFORM(EVALUATE("lcLocal") + EVALUATE("lcPlus") + EVALUATE("lcMore"))
? TRANSFORM(EVALUATE(EVALUATE('" '+EVALUATE("lcLeveled")+' "')) + + EVALUATE("lcPlus") + EVALUATE("lcMore"))

I visualize Type() to be hanging on the border of the execution context, throwing the param string at a billards table cushion to extract ev_type from the C struct. Eval() just raises her middle finger and stays in execution context, even if documented as "function".

Posted: **Fri Oct 25, 2019 8:58 am**

Robert,

We recently discovered that you can use a variable name for a local variable in the Type() function and this will work in VFP.

Adding to Thomas remarks: TYPE() returns the type of an expression that VFP can evaluate at a given context, "U" otherwise. So, TYPE("m.Variable") returns the type of m.Variable, if there is one, TYPE("PI()") returns "N", as does TYPE("1 + 1"), TYPE("DATETIME()") returns "T", TYPE("{^2019-10-25}") returns "D", and TYPE("TYPE('X')") returns "C".

I don't think TYPE() treats local variables differently as a special case. It just evaluates its argument at run time as a VFP expression and returns its type. As a compiler problem/use case, probably it falls in the same category of EVALUATE() (as Thomas mentioned) and macro expansion, I would dare to say from the (very far) outside...