The main goals – in details.
The DGL (Declarative GUI programming Language) Project is about developing a (Open Source) translator/compiler, and an interpreter, which will make it a lot more easier to develop desktop software.
The translator translates from a declarative programming language to GTK+ C code. Using a declarative language has several benefits. The benefits are (incomplete list):
- describe what the program should accomplish, rather than describeing how to go about accomplishing it.
- implement the use of actor based concurrency, that is, the declarative programming language will have implicit support for parallel programming of multi core microprocessors, without any effort of the programmer. The Actor based concurrency in DGL will use ideas from the Erlang programming language.
My thoughts about how to implement it (the 1st very abstract ideas).
The method I will use is like this.
1st I am using a radically different software developing method called: Language-Oriented Programming (LOP), and i will use this programming method more than once.
I am doing this technique more than once, because I need a hard working machine, that is, the computer, to do the tedious job of playing catch-up with the developers of the graphical user interface toolkit (GUI) – this first translator will work with GTK+ code. Another translator will work with the Enlighenment Foundation Libraries (EFL) much later, and I or another software developer can build other supporting backend translator(s), if I/him/her wants to do that.
The translator will probaly need some hand coded knowledge, wich act as kind of rules to compute the hard-coded knowledge database created by the supporting backend translator for a partikular GUI, fx. GTK+.
The result of a supporting backend translator is a knowledege database, wich is not a relational database, and not a NoSQL database, but a database written in a source code of a programming language (=micro language). The nice thing of having the output in source code is that is very quickly to do a lookup in the database – we are speaking of several orders of magnitude more quickly than compared to a relational database.
The knowledge database has a standardized layout, and is used by the front-end of the main translator, wich is translating the declarative programming language. It uses the information in the knowledge database to do semantic checks on the code.
The knowledge database is also used by the so called backend of the main translator. In that section of the translator it looks up information about how to do a isomorphic translation from the declarative programming language to source code. In the case of GTK+ it is C source code.
The declarative programming language will of course need to have a way of escapeing to a programming language where the programmer can tell the machine how a task in an event handler should be accomplished, but what being said, if you only want to change some properties, and say, open a pop up, you can still use the declarative programming language.
The escape to C feature will have syntax to generate C code that is a declaration of variable(s) with the correct type. Syntax for generating C code that sends a getter and/or setter message to the Application actor is also supported.
A much simpler escape to language should also be supported, Googles new Dart programming language looks nice.
I am thinking of using Dart as the 1st language you can escape to, and later adding support for escaping to C.
An interpreter far out in the future will also be useful, together with:
A GTK+ widget wich shows the GUI while you are codeing in the language. That widget could be used in an editor. Needless to say what that widget should have a plugin architecture so it can be extended in ways I never have thought of.
Currently I am doing some protypeing on the grammar with the ANTLRWorks tool – it has some nice features:
I will not use the ANTLR generator – it isn’t the right tool for the job in my opinion (YMMV), but it is good for the initial work.
I think a Common Lisp compiler together with Common Lisp macros would be a lot better tool, because Common Lisp macros is equal to rewriteing the parse tree.
No language wars, please! I consider different programming languages the best tool for different type of works. If you disagree, take a look at the Blub paradox (scroll down to find it).
Please note that I take the liberty to delete any comments posted here that I deem inappropriate, off-topic, or insulting. And I excercise this liberty quite agressively. So yes, if you comment here, I might censor you. If you don’t want to be censored your are welcome to comment on your own blog instead.
