Proposal to an extended Eval() function

[SvenP]

Hello,

While writing a program using AutoIt, I ran across a limitation in the language which I could not easily 'circumvent'. The program I'm making reads a two-colum text-file which contains an 'expression' and a name of a file to 'run' when the expression is true.

The problem is that AutoIt does not (yet) contain a function to evaluate an 'AutoIt'-expression containing in a string value.

The existing Eval() function came close, but works only on variables.

So I decided to try to 'extend' this function, so it can evaluate *any* AutoIt expression.

However, I have only the source code to AutoIt 3.0.102. It seems to work in that version, but since my original program was written in version 3.0.103 I could not really test it properly (the program uses GUI extensions).

How can I obtain the source code to version 3.0.103 to test my modification?

See the attachments for my first attempt.

It contains a text file with the lines I modified in the source and a test-program.

Mind that I added an option 'ScriptErrorsFatal', but that one is used 'indirectly' to stay compatible with the Pre-3.0.103 Eval() function.

Regards,

-Sven

New_Eval.txt

TestEval.au3

[Jon]

Hello,

While writing a program using AutoIt, I ran across a limitation in the language which I could not easily 'circumvent'.  The program I'm making reads a two-colum text-file which contains an 'expression' and a name of a file to 'run' when the expression is true.

The problem is that AutoIt does not (yet) contain a function to evaluate an 'AutoIt'-expression containing in a string value.

The existing Eval() function came close, but works only on variables. 

So I decided to try to 'extend' this function, so it can evaluate *any* AutoIt expression.

However, I have only the source code to AutoIt 3.0.102.  It seems to work in that version, but since my original program was written in version 3.0.103 I could not really test it properly (the program uses GUI extensions).

How can I obtain the source code to version 3.0.103 to test my modification?

See the attachments for my first attempt. 

It contains a text file with the lines I modified in the source and a test-program.

Mind that I added an option 'ScriptErrorsFatal', but that one is used 'indirectly' to stay compatible with the Pre-3.0.103 Eval() function.

Regards,

-Sven

Thanks.

I think this sort of extension was thought about before (this-is-me IIRC?) and my feeling at the time was to leave Assign/Eval as simple variable parsers and to create a VBScript like Execute() function that would run any line of code contained in a string instead. I've still not decided what is best - and it's going to be a 3.0.104 thing anyway.

[this-is-me]

You are correct, Jon. I would certainy be willing to accept either option, but may I ask why the implementation is so far away (or rather how quickly are you going to release 103)?

Edited January 4, 2005 by this-is-me

[Chris_1013]

Well, 103 has already been announced as a feature freeze. The obvious problem is that as you allow more features to slowly slip in, it'll press that release date further and further away. There's lots of cool stuff being mentioned but with luck we'll get a beta of 104 with all the goodies soon after a 103 release, so won't have to wait long... we shall see.

[SvenP]

Just being curious: Is already some code written for the future Execute() function?

Because while rewriting Eval() I ran into two problems:

1. How to handle parser errors

If the argument-string to the execute function contains an invalid expression (or an invalid statement), AutoIt cannot show the user what went wrong.

Especially when the argument is a variable.

An example:

$a="v=1"

$Result=Execute($a)

This would produce the error message:

$Result=Execute($a)

^ERROR

Error: Unknown function name.

To real clue for the user there.

How do you get around this? In my version (see previous attachments) I had to temporarily disable the 'FatalError' function.

2. How to make the difference between a statement and an expression

I read this remark in the VBScript Execute() description on MSDN.

Let take the following example:

$a="$x=$y"

$Result=Execute($a)

The logical result would be that the value of $y is assigned to $x. But in that case, I can never evaluate an 'expression' using the Execute() function.

It would be a nasty hack:

$a="if $x=$y then $Result=1 else $Result=0 endif"

$Result=Execute($a)

I don't think that will work properly. For this purpose VBScript and JScript have the Eval() function.

So that's why it sounded more logical to me to rewrite Eval() instead of making a new function like Execute(). The first one is for evaluating 'expressions', the second one is for executing 'statements'.

Something to think about, or am I just talking nonsense?

-Sven

[Jon]

No you are right. Thinking about it in bed last night (what a geek) and the only useful line you would be able to do in an Execute type functions would be a "$var = " type thing anyway. So might as well just have an Eval... I probably would just set an @error flag rather than add a scripterrorsfatal opt.

[SvenP]

Jon,

You're not the only geek around :-)

I've been scrutinizing the code for a way to set only the @error flag without being 'thrown out' by the FatalError() function.

I couldn't do it without introducing a kind of 'ScriptErrorsFatal' option, because in both the Lexer and Parser you call FatalError() in numerous occasions.

Since it's a quiet week at work, I wasted by bosses time with some C-programming; Here's my attempt for the Execute() function.

See attachments. Don't kill me if I'm dishonouring your precious source code with this one.

Regards,

-Sven

ExecuteTest.au3

ExecuteHelp.txt

execute.txt

[SvenP]

OK, this is still an highly debatable function, but I still couldn't resist modifying it in the 3.0.103 version.

My own Eval() function is now fully backwards compatible with the existing one.

It's not a proposal to add it in AutoIt. It's just FYI.

One nifty thing in my version; a slight modification in the Lexer had to be made, because Jon introduced the Great Lexer Cache (GLC :-). On each subsequent call to the modified Eval(), the nice Cache rembered the line from the first call and produced always the same result. Oh well, I just 'convinced' the Lexer not to cache linenumber 0.

See the attachment.

And why am I troubling myself in modifying this function? ...well that's all about another AutoIT-project I'm into (adjacent to the AutoIT-COM Project). More about that later in 'Scripts & Scraps'..

Regards,

-Sven

New_Eval.txt

[Angel]

Sven,

this could very useful. Thanks!

I hope this gets into 103.

Cheers,

Angel

[Chris_1013]

It's unlikely it'll get into 103. I think what we'll see is a final release of 103 (hopefully soon ), and then quite quickly after a beta of 104 with all the new and cool gubbins in it. Which suits me if it goes that way

[SvenP]

Just to complete the topic: I've improved the Execute() function to be compatible with 3.0.103.

The difference between Eval() and Execute():

Eval() returns a boolean result of the given expression. So: only 1 (TRUE) or 0 (FALSE).

Execute() returns the result of the executed string value. e.g. Execute("1+1") returns 2.

Note that the functions will run in the "current" context of the script. That means, when you use these functions inside another function in your script, then the given string will also be executed inside that function. I tell this, because with Execute() you can modify your "local" defined variables or call an UDF defined in your script.

An example:

$Globalvar = 2
$Result=MyFunc()
exit

Func MyFunc()
   Local $test

   $test=1
   Execute("$test=0")  // Will modify the local variable test

   Execute("$Globalvar = 0") // Will modify the global variable test

   Return $test  // returns 0
EndFunc

Sidemark: SlimShady wrote an excellent _Execute() UDF that simulates an execute() by running a scriptline with a new instance of AutoIT.exe. However, that one runs OUTSIDE the context of the current script.

NOTE: These functions do currently NOT EXIST in AutoIT. It's up to Jon if he wants to incorporate them or not.

Regards,

-Sven

New_Execute.txt

Edited January 19, 2005 by SvenP

[Valik]

Quite a large shotgun you've made for blowing one's foot off with. I already see one idiot on the forum incorrectly using Call(), I can't wait to see how many one-legged wonders such a function will create by stupid people doing stupid things with it.

Not an objection, just a random musing, really. I'm not opposed to such a feature or anything. Just giving advanced warning of stupid code potential.

[Jon]

Quite a large shotgun you've made for blowing one's foot off with.  I already see one idiot on the forum incorrectly using Call(), I can't wait to see how many one-legged wonders such a function will create by stupid people doing stupid things with it.

Not an objection, just a random musing, really.  I'm not opposed to such a feature or anything.  Just giving advanced warning of stupid code potential.

[BasicOs]

SvenP Sidemark: SlimShady wrote an excellent _Execute() UDF that simulates an execute() by running a scriptline with a new instance of AutoIT.exe. However, that one runs OUTSIDE the context of the current script.

I dont agree,

I find trivial , that _Execute() can be run simulating and even work better than INSIDE the context execute() as a UDF. Whith more for that conts.

please, dont say, It is not possible say better nobody has done YET. I see many times in this forum the word NOT POSSIBLE and I smile . Dont make limits to Human imagination.

(Albert Einstein)

Only two things are infinite, the universe and human stupidity, and I'm not sure about the former.( I should change  imagination instead)

(from Wolvereness).

NOTE: These functions do currently NOT EXIST in AutoIT. It's up to Jon if he wants to incorporate them or not.

The newly made functions are called UDFs, and they exist like any,when somebody makes it.

@SlimShady go on with your func but dont copy the execute() after today, make something new please.

@SvenP, I enjoy your scripting, I read you sometimes, I wanted only vindicate the not possible, you wrote more than a couple of times.

Edited January 19, 2005 by BasicOs

[SlimShady]

I swear I didn't copy. It just popped up in my mind.

It's a coincidence that I created the UDF 11 days after SvenP started this topic.

[BasicOs]

sorry, I didnt meant it, of course . I meant in the next future of your func you should find new ideas .

I Edited my former post.

Edited January 19, 2005 by BasicOs

[SlimShady]

Ideas?

I guess you didn't see the list.

[Angel]

If this enhanced Eval goes it, it could for instance also be used for using "inline" OnEvent functions.

For instance, I'd love to be able to say:

GUICtrlSetOnEvent(-1, "Exit 1")

This would be handy for attaching simple actions to your GUI elements. Right know you must create a a separate callback function for each, which for such simple actions seems overkill.

Or perhaps is just me being too lazy... ;-)

Cheers,

Angel

[Jon]

If this enhanced Eval goes it, it could for instance also be used for using "inline" OnEvent functions.

For instance, I'd love to be able to say:

GUICtrlSetOnEvent(-1, "Exit 1")

This would be handy for attaching simple actions to your GUI elements. Right know you must create a a separate callback function for each, which for such simple actions seems overkill.

Or perhaps is just me being too lazy... ;-)

Cheers,

Angel

The same callback can be used for multiple controls/event, then in the function you just check the @GUI_CTRLID to decide where it came from.

[BasicOs]

for Gui scripting, in the Examples wanted, I didnt see any working with GUIOnEventMode =1. which mode do you recommend for future use? In which cases?

Thanks

The same callback can be used for multiple controls/event, then in the function you just check the @GUI_CTRLID to decide where it came from.

<{POST_SNAPBACK}>