This is the mail archive of the guile@cygnus.com mailing list for the guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Guile scripting host?


[Apologies for not replying to you personally, but I'd rather not send to an
email address that appears to be a bulk mailing list!]

From: Dirk-Jan C. Binnema <bulkmail@dds.nl>
>
>On our beloved Win platform, there is the concept of 'scripting hosts':
>programs that use scripting languages to enhance their functionality. These
>languages, or 'scripting engines' are implemented through a couple of COM
>interfaces, and are able to interact with objects from the 'ouside world',
>like variables or COM components. You can even create a variable in one
>scripting language, and use it from another.
>
>[...]
>
>As a related note, it seems that this 'scripting host' stuff aims at some
of
>the same things the Guile project aims at. But instead of trying to make
>translators for any language to one language (ie. CTAX --> Guile), the
>scripting engines implement their own parsing, and a mechanism is defined
>for interacting with their scripting host (which may be MS-IIS (ASP),
>Windows Scripting Host, or any prog you'd like to add scripting capability
>to). Isn't the Scripting Engines approach a lot easier to implement than
the
>way Guile tries to do this? Are there any disadvantages to that approach?


Thanks for raising this question.  Even if you see MS as the Dark Side (I
don't), it's good to understand what they are doing and how it differs from
the GNU world.  The following is my understanding...

Scripting languages like Javascript and VBScript are no use on their own
unless they have something to operate on.  In the Windows hosts, objects to
operate on are obtained in one of two ways.  The first method is that a
script can instantiate and manipulate arbitrary COM objects, irrespective of
which host application the script is running in.  The second method is that
specific host applications provide application-specific "object models" that
can be manipulated by the script; for example (i) Internet Explorer provides
the Document Object Model, which gives you access to an HTML page and all
its links, frames, images etc. (ii) Excel gives you access to objects which
represent spreadsheet cells etc.

I don't know exactly how the object models are implemented, but it may well
be as COM objects that a host application declares at global scope just
before it starts running a script, so implementationally the boundaries
between these two methods may blur a bit.  And functionally, any script can
instantiate a WebBrowser object that provides some (all?) of the
functionality that you get from the DOM in IE.

So how does this compare to Guile?  First, Guile is a complete computer
language that is useful enough to write applications purely in Guile.
Second, the way that specific Windows host applications provide object
models that can be scripted is conceptually very similar to the way that GNU
applications wrap data and functions as smobs and methods that can be
scripted from Guile; Guile's smobs and methods are not as OO as the Windows
object models because Guile's OO support is not all there yet.  Third, the
ability of Windows scripts to instantiate and manipulate COM objects could
be mirrored by allowing Guile to instantiate and manipulate COM/CORBA
objects.  (In fact, maybe this has already been done?)  Fourth, the point
you raise about translators vs. specific engines will, I think, become
unimportant to ordinary users.  Once Guile has matured and important other
language translators are available, I imagine the translation stage will be
invisible.  It's certainly easier for "object model" developers if there is
a single core scripting language and multiple translators.  What makes you
think that there isn't effectively a translation stage in MS's scripting
languages?

All in all, it seems that there are fewer theoretical differences than at
first it appears.  In practice, it is probably true that there are currently
far fewer Guile-enabled applications than MS script-enabled applications
that are being actively scripted by users, but that's just a matter of time.
In principle, the Windows Scripting Host, which provides access to elements
of the Windows UI, may be compared to SCWM, which is scriptable using Guile.

To finish with a question...  As GNOME matures and CORBA becomes more widely
used, it seems that GNU application developers will have two possibilities
for making their applications extensible and scriptable: Guile and CORBA.
How does the developer decide which of these two is more appropriate?

    Neil