division problem in macro

[jbertram1957]

if executed in a macro, this results in 1, not in 1,67

?&("10/6")

[cpyrgas]

Confirmed, I think we need to enable compatible integer divisions in the macro compiler, at lest by default. VO always gives a floating point result, no matter of the setting for the application.

[jbertram1957]

Or make the compiler compatibility switch working for the macrocompiler , too

[RobertvanderHulst]

JB, To support this we need to persist the compiler option in the compiled app. We are doing that already at this moment for the compiler options /VO11 and /VO13. However, we are not doing that for /VO12 (Clipper compatible integer divisions). Btw if you code does not use literals:

PRIVATE Var1, Var2
Var1 := 10
Var2 := 6

Then the expression ?&("Var1/Var2") will be a division of 2 usual variables and that already automatically returns a floating point result. This will also happen when one of the 2 values is a literal and the other is a usual.

[jbertram1957]

Hi Robert.

Thank you for your answer

Yes, I have found this for me, too.

However, from a compatibility pov this is a very basic thing, which breaks all clipper style code. I am using for non-it user-edited small calculations , and can not explain them ☹. However, I can parse the entry and replace

t.e. “/6” with “/6.0” , so this may work

Gruß

Jörg

[cpyrgas]

Similar problem exists also with the = operator, as discussed in the online meeting today:

#pragma options (allowoldstyleassignments, on)
GLOBAL ggg AS INT

FUNCTION Start() AS VOID
Evaluate(" ggg := 1")
? ggg // 1, OK
ggg = 2
? ggg // 2, OK
Evaluate(" ggg = 3")
? ggg //  2, wrong

I will review also other compiler options for similar problems

[nvkokkalis]

Similar problem exists also with the = operator, as discussed in the online meeting today:

#pragma options (allowoldstyleassignments, on)
GLOBAL ggg AS INT

FUNCTION Start() AS VOID
Evaluate(" ggg := 1")
? ggg // 1, OK
ggg = 2
? ggg // 2, OK
Evaluate(" ggg = 3")
? ggg //  2, wrong

I will review also other compiler options for similar problems

The old-style assignment with = was supported in the macro compiler only for scripts in the FoxPro dialect.

I have allowed it in any dialect now, but only for scripts. Expression macros still don't allow it.

Should it be allowed there too? I'm worried that allowing it in expression macros may lead to problems.

[jbertram1957]

Hi Nikos

In macros, only “:=” is an assignment, “=” is compare “==” is exact compare (in strings) . This is in clipper, xbase, vo

So: do not allow it in macros, too.

Gruß

Jörg

[RobertvanderHulst]

Nikos, In the compiler in the FoxPro dialect the = operator is allowed for assignments and then only in the leftmost = operator on the line. So ? x = y = z is treated as: ? x := y = z

[nvkokkalis]

Nikos, In the compiler in the FoxPro dialect the = operator is allowed for assignments and then only in the leftmost = operator on the line. So ? x = y = z is treated as: ? x := y = z

OK, I can fix that as it was.

But what should Evaluate(" ggg = 3") do? Was Chris referring not to the VO dialect?

Also note that in the VO dialect Evaluate() does not treat the argument as script, so it still works as a macro.

[RobertvanderHulst]

I think in that example Evaluate(" ggg = 3") in the VO dialect this should return FALSE.

[RobertvanderHulst]

Also the line #pragma options (allowoldstyleassignments, on) should not (and can not) have effect on the scripts evaluated by Evaluate() or ExecScript(). so it should not be part of his example code.

[nvkokkalis]

Correct.

So, then I assume that Chris's sample is for the FoxPro dialect? Because it expects to work as an assignment:

Evaluate(" ggg = 3")
? ggg //  2, wrong

I did't see the dialect mentioned, so I assumed VO. Did I miss something?

[RobertvanderHulst]

I think you're right. But FoxPro did not have GLOBAL variables, only PUBLIC variables. So for a FoxPro example I would expect a PUBLIC ggg for for a VO example I would expect a GLOBAL ggg

[nvkokkalis]

OK, more questions. What if there is an expression list?

Should

x = y = z, z = x

Be treated as:

x := y = z
z := x

?

Because this is what my intention was with the change (although an additional fix is necessary). Before, it would be treated as:

x := y = z
z = x // this does nothing

[nvkokkalis]

So, I did the extra fix and enabled this only on foxpro. Is there something I'm missing?

[RobertvanderHulst]

I am get an exception now when running the macro compiler tests. I don't know if it is related: "Unable to cast object of type 'XSharp.__FoxArray' to type 'System.Object[]'." This happens on E:\XSharp\Dev\src\Runtime\MacroCompiler.Example\VoTests.prg:line 147

[nvkokkalis]

The tests are passing for me. Did you make any additional changes? (e.g. merge with some other branch)

[cpyrgas]

Correct.

So, then I assume that Chris's sample is for the FoxPro dialect? Because it expects to work as an assignment:

Evaluate(" ggg = 3")
? ggg //  2, wrong

I did't see the dialect mentioned, so I assumed VO. Did I miss something?

Nik, that's for all dialects. VO had an compiler option "Allow old style assignments" for this, and we have it too in X# also for this reason. In my sample I had included a

#pragma options (allowoldstyleassignments, on)

implying that the macro compiler should follow the rules of the standard compiler and allow = for assignments only if that option is enabled.

[RobertvanderHulst]

Chris, How do you suggest that we should set that option for the macro compiler?

[nvkokkalis]

I pushed an additional fix to support result statements and made a fix for complex expressions.

Note that the macro compiler has the AllowOldStyleAssignments option. However, as Robert mentioned, the /vo12 switch is not known at runtime. It is only a compile-time setting. Moreover, the preprocessor options are scoped. Even if the compiler switch became available at the runtime state, it would not be scoped. Currently, this option is set only for the foxpro dialect.

[RobertvanderHulst]

The tests are passing for me. Did you make any additional changes? (e.g. merge with some other branch)

I was accidentally using the new (X# 3) compiler to compile the code. So there is probably an issue with that compiler. Btw: I have removed support for the Vulcan Runtime and Vulcan types from that branch.

[cpyrgas]

Robert,

Chris, How do you suggest that we should set that option for the macro compiler?

As you said the compiler already emits code for the state of other compiler options like

RuntimeState.CompilerOptionVO11 := true

which can be used as options also for the macro compiler, I guess the same can be done for the other options as well.

I think we can ignore option modifications with pragmas and only use the global settings, that should be more than enough.

[RobertvanderHulst]

Robert,

Chris, How do you suggest that we should set that option for the macro compiler?

As you said the compiler already emits code for the state of other compiler options like

RuntimeState.CompilerOptionVO11 := true which can be used as options also for the macro compiler, I guess the same can be done for the other options as well. I think we can ignore option modifications with pragmas and only use the global settings, that should be more than enough.

So you suggest we should emit code (and add a property in the runtimestate) for other options as well? Which options do you suggest ?

At this moment we store: vo11 - Compatible numeric conversions vo13 - Compatible String Comparisons ovf - Integer overflow exceptions fovf - Float overflow exceptions fox2 - FoxPro Array support (fill with simple assignment, alow parenthesized array elements)

Which of these should be added: allowdot - Control if the DOT operator (.) can be used for instance members or not. allowoldstyleassignments - Control if the Equals operator (=) can be used for assignments az - Use Zero based arrays cs - Case Sensitive memvar - Should memory variables (PUBLIC and PRIVATE variables) be supported. modernsyntax - Disable some old Xbase compatibility features, such as && and * comments, bracketed strings etc. undeclared - Should the compiler allow undeclared variables vo1 - Allow Init() and Axit() as aliases for Constructor and Destructor vo2 - Initialize Strings -> could influence locals of type string in scripts vo3 - All instance methods virtual vo4 - Implicit numeric conversions vo5 - Implicit CLIPPER calling convention vo6 - Implicit pointer conversions vo7 - Implicit casts and Conversions vo8 - Compatible preprocessor vo9 - Allow Missing Return Statements vo10 - Compatible IIF Behavior (allows mixed types in TRUE and FALSE expressions) vo12 - Compatible integer divisions vo14 - Use Float Literals vo15 - Allow untyped Locals and return types vo16 - Generate Clipper calling convention constructors vo17 - VO Compatible BEGIN SEQUENCE .. END SEQUENCE handling

[cpyrgas]

I think those would be good to have:

allowoldstyleassignments - Control if the Equals operator (=) can be used for assignments az - Use Zero based arrays vo4 - Implicit numeric conversions vo6 - Implicit pointer conversions vo7 - Implicit casts and Conversions vo10 - Compatible IIF Behavior (allows mixed types in TRUE and FALSE expressions) vo12 - Compatible integer divisions vo14 - Use Float Literals

[RobertvanderHulst]

Ok, I will introduce these for X# 3

[cpyrgas]

Sorry guys, Jörg is right, in VO "=" is never an assignment operator in macros (no matter the compiler setting) and making it such has lead to problems with the "=" operator inside macros. Unfortunately I do not remember where I had found it being used like that in a macro, maybe it was some FoxPro code, but I am not sure.

For now, @nvkokkalis please roll back the change you made for it (assignment operator in macros)