The procedural database provides a database of functions that can be called by anything with access to the database. Currently, this means the pdb can be used by c/c++ and Guile, but other language bindings should follow. Extreme Wave's procedural database was inspired by the Gimp, but the actual implementation is fairly different. Currently the only limitation on the procedural database is that you can not define a new object type through the interface, but I would like to add this functionality.
Objects are any kind of three dimensional entity or primitive that exists in Extreme Wave. I put a lot of thought into how Extreme Wave handles objects, and I think I have come up with a good mechanism to extend Extreme Wave's object support. (Of course my ideas have yet to be field tested with other developers, so they are subject to change.)
All objects are c++ classes derived from the Object base class. Each new object overrides a few virtual methods that make up the API for any object. These methods tell Extreme Wave how it should draw the object, what properties it should save in it's native format, and other things like that. These objects can then be dynamically loaded into Extreme Wave. So when someone adds a new primitive to Extreme Wave you just need to compile and install that module.
Much of Extreme Wave's functionality comes from it's extensibility language, Guile. Guile is a library implementation of the scheme language (a dialect of lisp). Scheme is elegant and simple yet has proven to be more powerful than much bulkier scripting languages. Guile, in particular, intends to become the language of choice for all GNU applications that require extensibility.
What parts of Extreme Wave are/should be written in Guile?
Currently, non-native file exporters, and a lot of the user interface code is written in Guile. My intention in writing a lot of the interface in Guile is to make it easy to modify the interface. The guile-fltk wrapper is a hand written and fairly thin binding to the widget library. I can't claim to have noticed any performance loss in implementing it this way. I also beleive that most file format exporters should be written in scheme. This makes it easy to maintain existing formats, and easy to add lots of new formats. In the future, Guile may have additional rolls in the Extreme Wave framework..
What about other scripting languages?
It is my intention that Extreme Wave should support other scripting languages, but it doesn't right now. One point I am committed on is that I don't want any core Extreme Wave functionality to "depend" on any language other than Guile. I say this not because I am mean and I hate everything that isn't scheme, but because I think requiring people to install a dozen different scripting languages to get Extreme Wave to work is silly. I happen to know that there is a Python Fltk binding in development, so Python may be Extreme Wave's first "second language". I would also like to see a Perl binding to Extreme Wave and Fltk.
Guile/Scheme Resources
- Schemers.org is a very nice site with lots of scheme related information.
- The MIT Scheme Reference Manual differs from Guile quite a bit, but IMHO it is the best scheme reference on the web. I found this link on MIT's Scheme Home Page, which has lots of other scheme resources.
- Rice University's PLT Scheme Teaching Materials has some lecture notes and tutorials available.
- The Notes section on the Guile web site has some useful (albeit random) information on using Guile. The Guile reference manual is still under construction. What little that exists should have been included in your Guile distribution.
- Greg Harvey has written some Quick (& Dirty) Guile Docs about more advanced Guile language features.