Hello Alexandre,
Thanks for pointing this out. This reminds me that I should write a little summary of what would be involved in reproducing the RGL, and what our starting point was back in 2001. So here it is:
The main inspirations of GF-RGL were
- XFST, Xerox Finite State morphologies for several languages
- CLE, Core Language Engine, an SRI-Cambridge-Telia etc project for building syntax modules for some languages to be used in applications
The main lesson learned was
- make it open source and involve a community. CLE in practically disappeared because nobody had the rights to continue with it, and XFST was increasingly replaced by open-source variants
This brings us to
- the LinGO matrix, using HPSG, an open-source project
also an inspiration for the RGL, just a bit later, but still alive and active. The difference we wanted to make was
- think about non-linguist programmers as the majority of users
This led us to
- design GF and its module system in a way similar to programming languages, rather than grammar formalisms
- separate the linguist's view (the internals of the RGL) from the application programmer's view (the RGL API)
The closest GF counterpart of the LinGO matrix is thus the internal abstract syntax of the RGL. But when looking at the LinGO/DELPH-IN documentation back in 2003 and still today, I cannot see anything corresponding to the API. It is more of a linguists' project than of programmers'. And I think it would be quite a job to develop it into an API direction similar to GF. Not only is the starting point less friendly to that (with GF's formal distinction between abstract and concrete syntax), but even in the GF world, it took several years to bring the module system and the compiler into a state that smoothly supports the division of labour between linguists and application programmers in the way we do.
This said, HPSG has reached longer in their linguistic coverage in many languages, in particular in the English RGL: GF has nothing like that, and again it would take years of work to build it.
Of course, the nicest thing would be to share resources in a formalism independent way. This looks quite feasible in the case of morphological lexica, and is an ongoing practice already. But when it comes to syntax, I am less sure. Syntax code in GF and HPSG and other higher-level (above context-free) formalisms is essentially like code in different programming languages. There the practice is that each language has to build their standard libraries from scratch (think about for instance collections and generics in Java, C++, Haskell,...) An alternative is to enable foreign function interfaces (like from Python to C), but I cannot see very concretely right now how this would look for instance between GF and HPSG - and how much there would really be to gain. But of course we have mutual communication, for instance by co-organizing GEAF workshops (Grammar Engineering Across Frameworks), and see each other as allies rather than enemies.
ParGram (in LFG) could also be mentioned, but it used to be a proprietary system that was more difficult to learn from.
Regards
Aarne.