I have reconsidered my approach and I will be building an AST and creating a true compiler. I believe that this can be accomplished in a relatively short amount of time, however, it will delay development by several weeks at least. All of the previous features mentioned will still exist, the major change being that you will not need to rely on the editor's syntax checker at all. It also presents the possibility of adding many more features in the future since with a proper AST I will be able to manipulate the language in any way imaginable. I plan to leave this thread dormant for a while and possibly create a new one when new information is available.
Andromeda is broken and is unusable for anything resembling actual mapping. My numerous bug reports on the forum that show that even the most basic functionality is broken demonstrate that. Anything that works would be an improvement.
Progress update... the following features are done:
Combining all of the .galaxy files from a specified directory into an output script at a specified directory.
Script requirements, requires *, topological sorting to resolve script order
Public and private scopes
Map/script headers
Script compression options
Handling of multi-statement lines
Specific error reporting
The next step is to add proper handling of comments/block comments/string literals, as well as differentiating between identifiers in the global and local namespace. After that, initializers will be next, followed by hotkeys for syntax checking/testing.
Once the above is complete I will make a basic GUI and some documentation and do an initial release for people who want to use this tool as soon as possible.
A script's filename (dropping the .galaxy extension) is considered to be its scope identifier. Scopes are synonymous with individual files, so there will be no syntax to actually declare new scopes.
Requirements are expected to be listed as the first non-comment line of a .galaxy file. They are listed as "requires ScriptA, ScriptB, ScriptC", or you may use "requires *" to move a script to the bottom of the output. (Unsorted order with any other script that requires *)
Scoping is simple, you either put "public" or "private" in front of the declaration of a global or function. Public prefixes the scope identifier, such as "MyScript_FuncName" whereas private makes the function/global invalid for use outside of that scope.
To declare an initializer you will simply declare "private void Init()" inside your scope.
If debug mode is enabled, any line that begins with "DEBUG" will be replaced with a comment.
I have not put much thought into the syntax of other features yet, but getting all of the above working is my current goal.
The many reasons I am basing it on text manipulation:
Every feature that is needed for this project can be accomplished with text manipulation, and it is in fact much easier to handle that way.
Anyone who understands Galaxy code will be able to open the source code and modify it due to the simplicity of the code structure and the AutoIt scripting language.
It will be more than fast enough, even in an interpreted language.
I am not compiling anything, you will have to rely on Galaxy's build-in syntax checker for your syntax errors. However, I plan to provide extremely specific error information if you use a preprocessor feature incorrectly.
Would you rather have a project that can be working in a couple weeks and feature-complete in a couple months, or yet another project that will never be finished?
As far as popularity, it seems like almost no one actually uses Galaxy anyway, so I wouldn't be doing this if I cared for popularity. I plan to use it myself and if a few other people enjoy it, so much the better. :)
I do not plan to add support for data editor manipulation, that is beyond the scope of this project, and I don't see how it would be nearly as useful as it would have been in WC3.
There is already a way to perform syntax checking on your local .galaxy files, but everything must be setup correctly. If you feel like logging in to SC2Mapter IRC I can explain it to you there.
Scripting in Galaxy inside the editor should be enough to drive any reasonably intelligent person insane due to the numerous failings in the editor and the language itself. A few people have attempted to created Galaxy compilers to help relieve this situation, however, they are either dead or woefully buggy and borderline unusable (Andromeda).
After discovering some interesting methods I have decided to create a Galaxy preprocessor to deal with the situation and turn Galaxy into a usable language. In truth, there are only a few fundamental issues which hold Galaxy back from being a reasonable language to work with. A preprocessor is fully capable of dealing with these issues without the immense time requirement or complexity entailed by a full-fledged compiler.
Main features:
1.) Store your code as .galaxy files, not triggers - This preprocessor will allow you to save your code as .galaxy files within whatever directory/subdirectory structure you please.
2.) Script requirements - Galaxy's import system is unreliable once an imported script imports another script. The editor doesn't like it at all, and it may completely lose its ability to syntax check the resulting script file. This preprocessor allows you to specify which scripts require which other scripts, and merges the resulting output into a single script.
3.) Scoping - This preprocessor will treat each .galaxy file as its own scope, and allow you to create public and privately scoped globals and functions. No more worrying about clashing identifiers or using awkward names to avoid it.
4.) Initialization - An init function for each script that will automatically run in its own thread. A well-defined initialization order.
5.) Convenience features - This preprocessor will allow you to freely declare locals throughout a function and fix small known bugs in the Galaxy language.
6.) Conditional compilation - Debug mode will be supported, along with the possibility for other forms of conditional compilation.
7.) Script compression - Deleting whitespace and comments will be optionally possible.
8.) Macros - Text macros will be supported.
8.) Function pointers - Yes, OMG, it will be possible to create working function pointers.
10.) Structs - Simple structs with . syntax and dynamic creation/destruction should be available at some point.
11.) Simple/friendly GUI with options displayed.
12.) Hotkeys - Allows you to test or compile your map instantly, even when not looking at the editor.
13.) Enhanced autocompletion for NotepadPlusPlus - You will be able to automatically add/remove user-defined functions to/from your autocompletion file.
So why, you ask, is it possible to create such a tool in a relatively short period of time? It is because every one of these tasks can be accomplished through string manipulation and logic without having to build an abstract syntax tree or anything of that nature. It is also being written in a very simple scripting language called AutoIt, which has a rich library of support functions available which will greatly simplify a project of this nature.
I guess the next question is, how fast can it possibly be if you're writing it in an interpreted language? Isn't speed essential for this type of task? I was worried about this at first, however, I decided that the speed of development and debugging gained from using a higher-level language greatly outweighed any speed concerns. But if you are interested in a bunchmark, the amount of time it currently takes for it to read and alter 50,000 lines of code from 200+ files and output them into a single script file is less than 3 seconds.
In this thread (if anyone takes interest in it) I will provide an ongoing updates of the development progress and take any suggestions regarding features or syntax. However, please keep in mind the scope of this project and don't ask me to convert Galaxy into a fully OOP language or something like that.
Status update for anyone who was following this:
I have reconsidered my approach and I will be building an AST and creating a true compiler. I believe that this can be accomplished in a relatively short amount of time, however, it will delay development by several weeks at least. All of the previous features mentioned will still exist, the major change being that you will not need to rely on the editor's syntax checker at all. It also presents the possibility of adding many more features in the future since with a proper AST I will be able to manipulate the language in any way imaginable. I plan to leave this thread dormant for a while and possibly create a new one when new information is available.
Andromeda is broken and is unusable for anything resembling actual mapping. My numerous bug reports on the forum that show that even the most basic functionality is broken demonstrate that. Anything that works would be an improvement.
Progress update... the following features are done:
The next step is to add proper handling of comments/block comments/string literals, as well as differentiating between identifiers in the global and local namespace. After that, initializers will be next, followed by hotkeys for syntax checking/testing.
Once the above is complete I will make a basic GUI and some documentation and do an initial release for people who want to use this tool as soon as possible.
If you want to imagine what the general procedure will be while using this...
A script's filename (dropping the .galaxy extension) is considered to be its scope identifier. Scopes are synonymous with individual files, so there will be no syntax to actually declare new scopes.
Requirements are expected to be listed as the first non-comment line of a .galaxy file. They are listed as "requires ScriptA, ScriptB, ScriptC", or you may use "requires *" to move a script to the bottom of the output. (Unsorted order with any other script that requires *)
Scoping is simple, you either put "public" or "private" in front of the declaration of a global or function. Public prefixes the scope identifier, such as "MyScript_FuncName" whereas private makes the function/global invalid for use outside of that scope.
To declare an initializer you will simply declare "private void Init()" inside your scope.
If debug mode is enabled, any line that begins with "DEBUG" will be replaced with a comment.
I have not put much thought into the syntax of other features yet, but getting all of the above working is my current goal.
The many reasons I am basing it on text manipulation:
As far as popularity, it seems like almost no one actually uses Galaxy anyway, so I wouldn't be doing this if I cared for popularity. I plan to use it myself and if a few other people enjoy it, so much the better. :)
I do not plan to add support for data editor manipulation, that is beyond the scope of this project, and I don't see how it would be nearly as useful as it would have been in WC3.
There is already a way to perform syntax checking on your local .galaxy files, but everything must be setup correctly. If you feel like logging in to SC2Mapter IRC I can explain it to you there.
Scripting in Galaxy inside the editor should be enough to drive any reasonably intelligent person insane due to the numerous failings in the editor and the language itself. A few people have attempted to created Galaxy compilers to help relieve this situation, however, they are either dead or woefully buggy and borderline unusable (Andromeda).
After discovering some interesting methods I have decided to create a Galaxy preprocessor to deal with the situation and turn Galaxy into a usable language. In truth, there are only a few fundamental issues which hold Galaxy back from being a reasonable language to work with. A preprocessor is fully capable of dealing with these issues without the immense time requirement or complexity entailed by a full-fledged compiler.
Main features:
So why, you ask, is it possible to create such a tool in a relatively short period of time? It is because every one of these tasks can be accomplished through string manipulation and logic without having to build an abstract syntax tree or anything of that nature. It is also being written in a very simple scripting language called AutoIt, which has a rich library of support functions available which will greatly simplify a project of this nature.
I guess the next question is, how fast can it possibly be if you're writing it in an interpreted language? Isn't speed essential for this type of task? I was worried about this at first, however, I decided that the speed of development and debugging gained from using a higher-level language greatly outweighed any speed concerns. But if you are interested in a bunchmark, the amount of time it currently takes for it to read and alter 50,000 lines of code from 200+ files and output them into a single script file is less than 3 seconds.
In this thread (if anyone takes interest in it) I will provide an ongoing updates of the development progress and take any suggestions regarding features or syntax. However, please keep in mind the scope of this project and don't ask me to convert Galaxy into a fully OOP language or something like that.