AutoHotkey Community

Care to share which program it is? I'd like to try it myself.

HotKeyIt, I've thought about rewriting all AutoHotkey functions in C#. There would then be a converter that translates the AutoHotkey code into .NET compatible code and includes any functions needed by the script. All the variables could be stored in a global associative array and each function with its own scope can have its own set of variables.

I realize that IronAHK is/was being worked on but an interpreter sounds much more difficult to implement than a converter.

I think this is very practical because all someone would need to do is convert a command or function to its C# equivalent. Anyone with more C# knowledge could work on the converter/parser separately from the functions. So if someone has 30 minutes every week to spend on it, that can actually be a big help.

For example, SubStr()
It took like 5 minutes to write that in VS and it's good enough quality for a project like this. Like I said, the converter has the hardest job and even that isn't that bad. If you look at the above functions, about half the lines above just convert strings to integers.

The limitations of something like this would be that it has to be compiled using a C# compiler and that I don't see dynamic functions being possible (exception: class members).

Advantages would be speed, exe size and (possibly) cross-platform.

_________________
aboutscript ⍟ apps ⍟ scripts
Any code ⇈ above ⇈ requires AutoHotkey_L to run

I believe IronAHK is/contains a compiler, not an interpreter. Also,

Ahh. Thanks for the info.

_________________
aboutscript ⍟ apps ⍟ scripts
Any code ⇈ above ⇈ requires AutoHotkey_L to run

@Frankie & Lexikos

This is exactly what IA does.
An Lexxer/Parser is needed in any case.

Part of IA is the Rusty.dll. This dll is a collection of C# Functions Equivalent to the AHK Build-in Functions. There are some missing Features, but for Windows most Commands/Functions work as expected.

Now, to create C# which calls the approperiate AHK Build-in Commands, you need a full blown compiler.
IA parses the Skriptcode, and creates an CodeDOM representation - (This is an AST with full type info)

I'm currently working on a new Version of the Parser --> AST/CodeDOM Generator to avoid using a Dictionary like it is done in AHK/IA.
Instead, I try to create real Fields/Variables like it would be done if you write c# code ad-hoc.
This is possible because I use a Master Class, where as Globals are Master-Class Fields. User Defined Classes are nested in the Master Class, so Access to Methods/Globals defined in the Masterclass works.
All Build-In Functions/Properties are added as Members to this Master Class too.

No need for a Dictionary.


Dynamic functions aren't a problem (delegates) - I think I can support anonymous Methods / Lambdas either.

The most problematic part are dynamic Variables. They will get a very limited support. It's possible to use Reflection to get most Variables, but not all of them; eg: A local Variable in a Method will loose it's identifier info after compilation.

so long

BTW:
To stay on Topic: IA has a Compiler (smart compiler) which just adds those Methods from Rusty to the compiled assembly which are referenced.
This is IMHO not that important for .NET Assemblies as they are very thiny (but require the fat .NET Framework installed)

_________________
http://securityvision.ch
AHK 2D GAME ENGINE

We don't need #exclude. We need the compiler to find out itself which libraries are needed. Also we need the compiler to figure out which functions/variables that you created in the script are not being used and (ask if) remove them if not. I included a lot of functions in my script to only use one or two.

The problem with that might be the dynamic functionalities AHK has: we don't have Eval(), but you can dynamically call functions (even built-in), use dynamic variables etc.

_________________
RECOMMENDED: AutoHotkey_L

github - ImportTypeLib
Win7 HP SP1 32bit | AHK_L U 32bit

Addition to my previous post: This happens a lot when you include a script, most functions go unused.

Das könnte man deaktivieren.