Re: Small embeddable scripting language ?

[Malcolm Tredinnick <malcolm commsecure com au>]

On Thu, Nov 28, 2002 at 09:37:48AM +0530, Biswapesh Chattopadhyay wrote:
> I'm looking for a scripting engine for Anjuta. It would be used for
> extending functionality through user-defined tools as well as a
> templating language for wizards. The requirements are:
> 
> 1) Small (since we'll probably have to distribute it with Anjuta)
> 2) Reasonably fast
> 3) Embeddable from C programs
> 4) Ability to register/call C functions
> 5) Free

All sound reasonable, except possibly for (1) (see below).

> My guess is that we are not the first project looking for this since it
> seems to be a pretty obvious thing to do once things get bigger than a
> certain size. So far, I like Lua (http://www.lua.org/) - however, the
> syntax seems a bit weird - I'd prefer a minimal learning curve for
> people (including me).
> 
> So, my question is: is there any 'official' GNOME policy for this ? If
> not, what do you suggest ? What did porojects facing a similar situation
> choose ? Can someone point me to a reasonably simple implementation ?

A number of projects ship bindings for scripting in different languages.
Sometimes the scripting possibilities available to a user depend upon
what they already have installed on their system. If you can pick a
fairly common language (e.g. Perl, Python, ...), then it's not really
too onerous to assume the user already has it installed.

Some examples from other projects (off the top of my head). Not all of
these are GNOME, but they are pretty widely used examples...

- Sawfish: scripting in Scheme. Depends upon librep to provide the
  language itself. Since I don't know of anything else on my system that
  uses librep currently, it's safe to think of Sawfish as shipping its
  own language interpreter.

- Emacs: Uses Lisp. Ships its own language interpreter and truckloads of
  code. Fairly large download, too (not coincidentally).

- The Gimp: scripting in a Scheme variant (support built in?). Also
  possible to script in Perl or Python, both relying on the language
  already being installed and a couple of extra packages. You can decide
  whether to build in the Python and/or Perl stuff at build time.

- Xchat: scripting in Python, Perl (and others?). Again, compile-time
  switches determine which support gets built and it relies on the
  languages already being installed.

You can see here (from looking at these projects, I mean) that these
language choices all satisfy your requirements, although in each case
you need to build some kind of wrapper library to enable C functions to
be called from the language (but since you need to compile the C
functions anyway, this is not a great burden).

I'm not exactly sure why you want to ship the language with the
application, since it feels more natural to me to use one of the
languages that are likely to be on the user's system. So I may be
steering you in the wrong directorion through ignorance. I'm also
biased, since I would add Python scripting in a heartbeat, so my
rose-coloured glasses may be interfering.

Cheers,
Malcolm

-- 
The only substitute for good manners is fast reflexes.