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] |
[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