35 replies to this topic

[Manadar]

Threads like AutoIt object oriented preprocessor always catch my eye. Primarily not because I really want object oriented AutoIt (I do btw - a lot), but because people are using AutoIt in fun and creative ways. That gives you, reader, a pretty good idea of what this thread is all about. It's a mind teaser, to provoke thought.

Look at what Kip has done with his preprocessor (and a history of others before him), the possibilities are seemingly endless. By creating a preprocessor for AutoIt (not the kind that simply improves execution speed), we can do more with the language than what is officially available to us. The question central to this thread is:

What cool and fun things can we do with AutoIt?

I'm always trying out new languages when I get an opportunity. With seeing more and more of other languages always comes envy of other language features. I am quite sure that anyone who reads this and knows another language will go "True, i've always wanted [...] in AutoIt". There are possible through a preprocessor which produces (even neatly looking) AutoIt code to reach this goal.

I've some simple ideas to get the thread started.

When keyword
inspired by await

$finished = False

When PixelGetColor(100, 100) == 0xFF00FF
  MouseClick("Left", 100, 100)
  $finished = True
EndWhen

While Not $finished
  Sleep(100)
WEnd

This can be compiled to:

$finished = False

AdlibRegister("__implDetail__When01", 100)

While Not $finished
  Sleep(100)
WEnd

Func __implDetail__When01()
  If PixelGetColor(100, 100) == 0xFF00FF Then
    MouseClick("Left", 100, 100)
    $finished = True
  EndIf
EndFunc

The trick is to determine the right amount of sleep it needs automagically (it's a private implementation detail after all). Perhaps 100ms is a good default choice, but some will need to define it themselves.

Inline functions (maybe even called delegates)
Inspired by Lua inline functions.

HotKeySet("a",  Func()
         Send("b")
    EndFunc)

Actual code:

HotKeySet("a", "__GenericFunctionName01")

Func __GenericFunctionName01()
  Send("b")
EndFunc

How this works is that any time you use Func() it is replaced with a function name (as string), and the function statements are preprocessed into a new function with that name.


Moar!

[Mat]

I think the best way to implement this would be a generic preprocessor that then has community written plugins. Ideally it would be AutoIt, as we all know that well, but I doubt it's feasible as a plugin language. The plugins would install hooks for the different syntactical elements and could then have a series of methods they can call on the script to change the output.

[James]

Man if we had closures and alike, I'd die a little.

Ternary would also be nice.

$aVal = true
$myVal = ($aVal ? "hello" : "world")

But I don't think that can be as easily processed as what you mentioned Manadar.

I can see this turning into a "I wish AutoIt had..." list. But hey..

[Manadar]

Man if we had closures and alike, I'd die a little.

Ternary would also be nice.

$aVal = true
$myVal = ($aVal ? "hello" : "world")

But I don't think that can be as easily processed as what you mentioned Manadar.

I can see this turning into a "I wish AutoIt had..." list. But hey..

That can be preprocessed into:

$aVal = true
$myVal = _Iif($aVal, "hello", "world")

Have a look in the help file for _Iif. We can include it if it's not already in the script.

It stands for "if and only if". I didn't know that for a long time. http://en.wikipedia.org/wiki/If_and_only_if

Also, let's make this an "I wish AutoIt had .. and let's add it right now" thread.

Edited by Manadar, 23 May 2011 - 05:51 PM.

[James]

Also, let's make this an "I wish AutoIt had .. and let's add it right now" thread.

I wish AutoIt had....

• Closures
• Ternary
• Was object orientated, optionally like PHP say....

All I can think of for now. I quite like the limitations in place, except for those mentioned above.

[Manadar]

I wish AutoIt had....

• Closures
• Ternary
• Was object orientated, optionally like PHP say....

All I can think of for now. I quite like the limitations in place, except for those mentioned above.

And how would you implement them? That's key.

[Richard Robertson]

New syntax is always fun to write. That's one of the things that always hung me on AutoIt.Net. There are features that .Net would require (or would be required for the AutoIter to target .Net) that are just weird to design while still remaining inside the AutoIt style.

[Manadar]

I was taking a shower and came up with this:

ConsoleWrite(a(3) & @CRLF)
ConsoleWrite(a() & @CRLF)

Func a($b = c())
  Return $b
EndFunc

Func c()
  Return 5
EndFunc

For the uninitiated, the above yields: Badly formatted "Func" statement.: Func a($b = c())

Preprocesses into:

ConsoleWrite(a(3) & @CRLF)
ConsoleWrite(a() & @CRLF)

Func a($b = Default)
   If $b = Default Then $b = c()
   Return $b
EndFunc

Func c()
   Return 5
EndFunc

Abusing (or misusing) Default for this purpose yields a leaky abstraction. Perhaps it is better to use @NUMPARAMS for this purpose.

[Bowmore]

I was taking a shower and came up with this:

ConsoleWrite(a(3) & @CRLF)
ConsoleWrite(a() & @CRLF)

Func a($b = c())
Return $b
EndFunc

Func c()
Return 5
EndFunc

For the uninitiated, the above yields: Badly formatted "Func" statement.: Func a($b = c())

Preprocesses into:

Func a($b = Default)
If $b = Default Then $b = c()
Return $b
EndFunc

Abusing (or misusing) Default for this purpose yields a leaky abstraction. Perhaps it is better to use @NUMPARAMS for this purpose.

Why do you concider using Default in this manner to by a misuse of Default. I often use it like this.

[Manadar]

Why do you concider using Default in this manner to by a misuse of Default. I often use it like this.

I dug up an old thread, so it's possible you didn't read the first post. I'm looking at ways to use a preprocessor to transparently add functionality to AutoIt.

If you look at this bit of code:

ConsoleWrite(a(3) & @CRLF)
ConsoleWrite(a() & @CRLF)
ConsoleWrite(a(Default) & @CRLF)

Func a($b = c())
    Return $b
EndFunc

Func c()
    Return 5
 EndFunc

It's the functional equivalent of:

ConsoleWrite(a(3) & @CRLF)
ConsoleWrite(a() & @CRLF)
ConsoleWrite(a(Default) & @CRLF)

Func a($b = 5)
    Return $b
 EndFunc

Which has the following output:

3
5 (The result of calling c, since $b was not passed)
Default

Where as if you preprocess it into what I described above:

ConsoleWrite(a(3) & @CRLF)
ConsoleWrite(a() & @CRLF)
ConsoleWrite(a(Default) & @CRLF)

Func a($b = Default)
    If $b = Default Then $b = c()
    Return $b
EndFunc

Func c()
    Return 5
EndFunc

The result is:

3
5
5

This is how an implementation detail in a preprocessor breaks user code unexpectedly because of the leaky abstraction. You can (I think) fix it by using @numparams.

Edited by Manadar, 17 September 2012 - 01:23 PM.

[czardas]

Interesting thread Manadar. Been looking at this wiki article, though I imagine you are familiar with the complete history of this subject: Law of Leaky Abstractions states:

All non-trivial abstractions, to some degree, are leaky.

How long was you in the shower?

[Manadar]

How long was you in the shower?

10 minutes, I'm a huge fan of Joel Spolsky. His blog is great.

Edited by Manadar, 17 September 2012 - 01:40 PM.

[czardas]

The theory of programming is very interesting indeed. I sometimes wish I had discovered this much sooner, but that's how the cookie crumbles. I hope the shower didn't leak as much as the code.

[Mechaflash]

Anything that improves on speed of execution and/or coding time, and that eases the programming process, I'm down for it... as long as the additions don't take away from the ease of use of AutoIt and become a complex programming language.

The idea of adding features are great, as long as it doesn't increase the time it takes to get from idea to deployment.

[guinness]

Ternary would also be nice.

Seems like your wish finally came true.

[dany]

When I wrote my first UDF I declared all variables as Local, assuming that just as in perl packages, these variables would only be visible to the functions in the UDF but otherwise hidden for the rest of the script.
Unfortunately this wasn't the case. I think this would be a good feature (data encapsulation), although being somewhat like a closure I can imagine it's very hard to actually implement.
Just my two cents.

Seems like your wish finally came true.

Cool, I was wishing for ternary as well although _Iif() works just fine.

[James]

Cool, I was wishing for ternary as well although _Iif() works just fine.

It's a feature that IMHO should always have been in the language _Iif is ugly and limited.

[dany]

_Iif is ugly yea, but I personally haven't run into problems with it sofar. Now I got to find me a piece of wood to knock on...
I agree with your humble opinion though. Ever since I first learned about ternary (PHP) I've used it left and right where I could. It's a great shorthand for simple If...Else statements.

[jaberwocky6669]

as long as the additions don't take away from the ease of use of AutoIt and become a complex programming language.

Also could be stated: "as long as the additions don't take away from the ease of use of AutoIt and become a complex programming language because I don't like change and I don't want to learn."

[James]

_Iif is ugly yea, but I personally haven't run into problems with it sofar. Now I got to find me a piece of wood to knock on...
I agree with your humble opinion though. Ever since I first learned about ternary (PHP) I've used it left and right where I could. It's a great shorthand for simple If...Else statements.

There are times when it's best not to use it though...