Some peculiarities of the MExec function behavior

[leon-ts]

The MExec function has a difference in behavior in X# and VO when a compiled expression that returns a CODEBLOCK is passed into it.

Code sample:

LOCAL cS AS STRING
LOCAL cbCompiledS AS CODEBLOCK // AS STRING in VO
LOCAL uResult AS USUAL
	
cS := "{|| STR(MY_DB_FIELD,1) }"
cbCompiledS := MCompile(cS)
uResult := MExec(cbCompiledS)

The workarea containing the MY_DB_FIELD field is not open yet. That is, the codeblock is pre-created before the opening of the workarea, in which it will be evaluated.
In VO, the MExec function does not generate an error, but "sees" that the code is a codeblock, creates it, and returns it to the calling program.
In X#, the MExec function throws an exception that the variable does not exist (as I understand it about MY_DB_FIELD).

[RobertvanderHulst]

Leonid,
What I see in VO is that:

• MCompile(cS) returns a string
• MExec(cbCompiledS) returns a _Codeblock
• Eval(uResult) throws the error when the table is not open

What we are doing in X# is

• MCompile(cS) already returns a _CodeBlock
• MExec() tries to evaluate the codeblock and throws the error
  I will see if I can 'teach' MExec() to not evaluate the codeblock.
  It will be difficult to make MCompile() return a string

[leon-ts]

Robert,

Eval(uResult) throws the error when the table is not open

Yes, if you then call Eval when there is no workarea with the corresponding field, then an error occurs. And it is right. The question is precisely in the MExec function, when a codeblock is passed to it, which also generates a codeblock. It shouldn't crash, but should return the nested codeblock. This is how it worked in VO and this feature is used by existing programs.

It will be difficult to make MCompile() return a string

This is not necessary. We have already successfully translated the VO code to X#, replacing the compiled codeblocks from STRING to CODEBLOCK. This works great and is even faster than VO!

[RobertvanderHulst]

Leonid,
Add this to your own project for now to solve the problem until you get the new runtime:

FUNCTION MExec(oBlock AS CODEBLOCK) AS USUAL
IF oBlock IS XSharp._Codeblock VAR cb .AND. cb:IsBlock
    RETURN oBlock
ENDIF
RETURN Eval(oBlock)

[leon-ts]

There the idea is that the MCompile function creates a codeblock, which creates another codeblock. If you look at my sample code above , then cbCompiledS contains code that can create a codeblock of the folowing type: "{|| STR(MY_DB_FIELD,1) }". And when the MExec(cbCompiledS) function is executed, a new codeblock is created, described in cbCompiledS.

[leon-ts]

Robert,

Add this to your own project for now to solve the problem until you get the new runtime:

I'm not sure if this code is returning the correct result. In fact, it just returns a copy of the codeblock passed to it. In reality, a new codeblock should be created with different variable addresses. I'll give you a more visual example to show how this code works in VO. To do this, I will give its analogue without using MCompile/MExec:

LOCAL cS AS STRING
LOCAL cbCompiledS AS _CODEBLOCK
LOCAL uResult AS USUAL

cS := "{|| {|| STR(MY_DB_FIELD,1) } }" // Codeblock nested in another codeblock
cbCompiledS := &cS // Here we got the codeblock that when executed, can creates new codeblocks of the form {|| STR(MY_DB_FIELD,1) }
uResult := Eval(cbCompiledS) // New codeblock of the form {|| STR(MY_DB_FIELD,1) }
Eval(uResult) // Error. And it is right.

[leon-ts]

Robert,
I researched the issue further and ran some tests. Basically, if the _Codeblock type is immutable, then your proposed fix will not differ in behavior with VO. In the initial example, the MExec function in VO creates a new codeblock each time, so it always takes STRING as a parameter. That is, it has no choice but to create new objects. But in X#, the MCompile function and the MExec function initially work with codeblocks. I only worried about the immutability of the codeblock object to match the VO behavior.

[RobertvanderHulst]

Leonid,
At this moment the properties of the _CodeBlock class are not immutable.
For the next build I will make all of the properties INITONLY which makes the object immutable.

[RobertvanderHulst]

Implemented in f66a2ca

[leon-ts]

Robert,
There is a suggestion for a small optimization. But to be honest, it can lead to some inconvenience in the application code. So I'll just leave it here as an idea for your consideration.

The MCompile and MExec functions are designed to work in pairs. At least that's how they were conceived in VO. Considering this, as well as the fact that in X# the MCompile function always returns the _Codeblock type (with an underscore at the beginning of the name), then the oBlock parameter in the MExec function can also be made of the _Codeblock type instead of CODEBLOCK. Then in the body of the MExec function there will be no need to check for IF oBlock IS XSharp._Codeblock VAR cb.

[leon-ts]

Addition to my previous post about optimization.
A better solution would probably be to simply add an overload for the MExec function.

For example:

FUNCTION MExec(oBlock AS CODEBLOCK) AS USUAL // original MExec
	IF oBlock IS XSharp._Codeblock VAR cb .AND. cb:IsBlock
		RETURN oBlock
	ENDIF
	RETURN Eval(oBlock)

FUNCTION MExec(oBlock AS _CODEBLOCK) AS USUAL // overloaded MExec
	IF oBlock:IsBlock
		RETURN oBlock
	ENDIF
	RETURN Eval(oBlock)