I thought I'd comment with some of my opinions on the proposal/project  
presented by Andreas_P. I have included the original post in its  
entirety at the end of this mail (as it's been a while since it was  

Over the years, GIMP's plug-in/extension system has remained fairly  
language agnostic. In addition to the original C and Script-fu, there  
have been implementations for Perl, Java, Python, C#(Mono), Lua,  
Javascript, and Ruby. There should be no real objection should someone  
wish to provide support for Yet Another language or even another  
dialect/implementation. However, should the goal be incorporation  
within the "official" GIMP distribution -- or supplanting of Script-fu  
with another Scheme implementation -- then it would be necessary to  
gain a broader acceptance from the project's developers.

Script-fu, both the original SIOD-based and the current  
TinyScheme-based implementations, is inarguably limited in capability,  
but it is important to understand the reasons behind the limitations  
when considering alternative GIMP extension languages. In many ways,  
Script-fu's limitations prove to be beneficial and offer advantages  
over other, more capable alternatives. Hardly any of the limitations  
are particularly attributable to the fact that Script-fu uses Scheme  
as its basis, other than perhaps Scheme's non-algebraic syntax for  
formulas and its lack of popularity amongst the general programming  
community. (There may be some issues that result from the specific  
Scheme implementation; e.g., unit testing support).

Script-fu's main limitations are that it is restricted from  
interfacing directly with libgimp -- it only has access to  
functionality as provided by the Procedural DataBase (PDB) -- and that  
it does not support usage of external libraries or modules (e.g., SF  
can't produce a customized GTK dialog window or employ a third-party  
FFT algorithm). These limitations are both artificial and by design  
(TinyScheme supports extensions and external bindings, but access to  
these is disabled in Script-fu).

Nonetheless, it is because of this restriction that a Script-fu script  
can be relied upon to work with all platforms without any dependency  
on libraries/functionality not included in a GIMP install. While  
Python-fu may itself be bundled with the official GIMP distribution  
(and thus not depend upon Python being installed on the host system)  
and a Python-fu programmer might be able to write a plug-in which  
limits itself to using only the GIMP-provided functionality, it is not  
uncommon that Python scripts "import" functions from external  
libraries which may not be available on the user's system; or worse,  
are not available for the user's platform. This creates a mini version  
of "dependency hell" and in practice distributing such plug-ins can be  
more problematic than distributing C-based plug-ins (which can  
statically link the necessary libraries).

I say this not to criticize Python-fu (or any of the other more  
capable plug-in languages), but to highlight that the "module"  
functionality provided by R6RS does not particularly resolve any  
issues for current TinyScheme. I currently have an "sflib" file that  
contains several dozen convenience functions which I often employ  
within scripts I'm writing; however, I include the functions by  
copying the "library" code to my script, defining it within a local  
scope. Yes, this results in duplication of code and all the negative  
aspects that entails, but the alternative is that my script should  
fail unless the users have my library file installed on their system.

This issue is not one of modularization, encapsulation, environment  
scopes, or any number of "advanced features" in modern high-level  
programming languages; it is a matter of distribution of dependencies  
not included in GIMP by default. The only way to properly resolve the  
issue would be institution of a repository/packaging system with  
automatic dependency resolution a la Debian's apt-get (while providing  
cross-platform support). This is certainly doable -- in fact the G'Mic  
project does a pretty fair job of implementing this in their  
third-party offering -- but in my opinion this challenge should be met  
before any script or plug-in language can expect to supplant Script-fu  
in GIMP.

I don't mean to sound negative, in fact I would personally encourage  
your project to pursue adding Racket support to GIMP. However, you  
should initially approach it from the standpoint of producing a  
self-contained, third-party extension which provides its own  
infrastructure for distribution and maintenance of Racket-based GIMP  
add-ons. I would even be interested in participating in such a  
project. If successful, then later on the GIMP project might see its  
way clear to incorporating your offering within the official GIMP  


Quoting Andreas_P:

> I hope that this email was not being posted several times here
> Hey all,
> I think I did loose the previously designed letter which I thought,
> having sent to Kevin Cozens.
> Now I have to write the whole letter again, hoping for him, that he is
> on this list, from time to time.
> It sounded like that:
> Dear Mr. Cozens,
> Thank you for contributing to GIMP!
> [For the sake of clarity I have to introduce myself: My name is Andreas
> Posur and I am a student on a big technical university inside Germany,
> enrolled in BSc. EECS]
> I got the feeling that Script-Fu / Tiny-Fu (SIOD) isn't well recepted
> because of "old & unsexy"...
> quote: from the internet research.
> I personally can support this statement. And I had some "REALLY"
> difficult problems to get a proper "unit testing" within R5RS
> (tinyscheme).
> Now my proposal: Just look at the upcoming (brand) new version of
> "racket" which is nothing else than the newly renamed and rebranded
> "PLT-Scheme". PLT is (in case you don't know) the bunch of hackers who
> are refining the elements of R6RS-Scheme to a mixture which can sb.
> call "impressive"...
> [quote
> Lazy - Functional - Reactive - OO - Macros (powerful, hygenic) -
> Delimited continuations - Module system (dynamic)
> Not too mention the basics, eye opening approaches to XML and Web, an
> IDE, debugger, contracts, typed/dynamic language, jit, Android
> development, ... and on and on.
> The talent of the core PLT group is outstanding. Matthias Felleisen for
> example was awarded an ACM Fellowship in 2006 for contributions to
> programming languages and development environments. His academic
> publications are right up there with the best out there, yet he spends
> as much time focused on the foundational aspects of teaching kids, and
> students as high brow papers, and the real world demands of
> programming. And the rest the core are not too shabby either.
> /quote] taken from: http://news.ycombinator.com/user?id=boskone
> The Programming Languages Teaching Website: http://www.plt-scheme.org
> will be transferred to plt-racket.org
> DrScheme [IDE] will be DrRacket, MrED will be gracket, and mzscheme
> will come out as racket.
> My main problem is that only Kevin probably will have the insights,
> what has to change and what not in terms of tiny-fu and tinyscheme, he
> developed the interpreter connector.
> So if anybody is able to help me (and perhaps later others with this) I
> would really appreciate that.
> My target is finally to get a powerful, ease of use, sexy Scheme
> derivate running and implementing GEGL Operations/Services/Actions that
> PhotoShop would have to fear...
> Greetings from Germany, yours sincerely: Andreas Posur
> (And when I have the time then I would do some basic bughunting (my c
> skillz aren't that good yet)...)

Gimp-developer mailing list

Reply via email to