Lambda the Ultimate

Since Ehud shows a prolonged interest in Little Languages I think he may appreciate this link:

http://discuss.fogcreek.com/joelonsoftware/default.asp?cmd=show&ixPost=1303&ixReplies=5

Joel Spolsky runs the successful Joel on Software weblog where he provides opinions on software development. Joel’s company, FogCreek, has just released a product called CityDesk, a product for managing web sites. CityDesk provides a simple scripting language called CityScript. This is particularly interesting because of Joel’s history: the program manager that designed VBA for Excel. Scroll down the page to read Joel’s motivation for electing to design a new little language instead of using VBA (or VBScript or Jscript.) Note that I’m not affiliated with FogCreek in any way, nor have I ever used their software.

One of the things that seem basic in this day and age is to expose domain specific objects to the script programmer. So the same scripting language can be used with various host environments, each supplying its own native objects.

I don't know a thing about VBA internals, but I am nto sure I understand why you need to say [A1] instead of A1. In Rexx, for example, if a string is not understood by the language it is passed to the host environment.

I once wrote a host env for Rexx, and it was quite simple to override the variable lookup mechanism (IIRC).

All this, of course, leads to the more interesting question of control structures. A good DSL should provide taylored control structures, reducing the effort needed to use more general control structures. Yes, if the original host language is powerful enough, this is just syntactic sugar.

I don't know how much of this stuff was in from the get go (the time when Joel worked at MS) but current Windows script integration is based on a set of COM interfaces, such IActiveScript, IActiveScriptParse and IActiveScriptSite (note that by current I mean prior to .NET). These interfaces define the interactions between the script and the application that hosts the script. These interfaces are intended to be language neutral. Using these interfaces you can easily add objects to the script's namespace (e.g. Evaluate from Joel’s example), but AFAIK they don't provide a means to take over the script engine's variable lookup. This may be the result of lack of foresight but it may also have to do with the difficulty in writing a lookup mechanism that's language agnostic. Or it may be that VBA's developers didn't want to burden the application programmers with having to write lookup code at all. There is one benefit I can think of for [A1] over A1: it makes it clear that this isn't just a regular script variable.

BTW, more troubling to me is the second part of this item, the default property. If an object x has a default property p, assigning to x actually means assigning to p. This forced VB's developers to add the abominable Set statement:

To me, this is the epitome of bad language design. Fortunately Set seems to be gone from VB.NET.

Funny that Joel should think that For Each is such a unique idea. But giving credit where it's due, VB's with block is the best implementation I've seen of this (generally lousy) bit of syntactic sugar.

Dan, maybe you'll be able to help me with my Windows scripting question?

Many resources about scripting the Windows environment can be found in the MSDN site. Specifically check out:
http://msdn.microsoft.com/library/default.asp?url=/nhp/Default.asp?contentid=28001169
There is also lots of information in the MSDN Magazine site:
http://msdn.microsoft.com/msdnmag/
Such as Dino Esposito’s “Cutting Edge” column:
http://www.microsoft.com/mind/defaulttop.asp?page=/mind/0698/cutting0698.htm&nav=/mind/0698/inthisissuecolumns0698.htm
See also:
http://www.microsoft.com/mind/defaulttop.asp?page=/mind/0698/cutting0698.htm&nav=/mind/0698/inthisissuecolumns0698.htm
and
http://www.microsoft.com/mind/defaulttop.asp?page=/mind/0698/cutting0698.htm&nav=/mind/0698/inthisissuecolumns0698.htm
Unfortunately, as far as I can tell, from a technical perspective, these articles require more than a passing familiarity with COM. Still you may find them useful.

Surprisingly (or not) I can't seem to find much else. The only other interesting resource I've managed to uncover is:
http://www.ddj.com/documents/s=1520/ddj0002as/do200002as001.htm

If you like, I can whip up a general overview of Windows scripting technology, but it may take me a while (hopefully before .NET is released and makes this stuff obsolete.)

It seems you gave three links to the same article though. It is a good introduction, but one link owuld have been enough...

What I was loking for was a simple howto document, telling you how connect your own language into the scripting architecture. Specifc insturctions for people who know how to use a C++ compiler, but that's about it.

If you can write something of this sort, I'd be very happy to read it. I think this can be a valuable resource, since it would make embedding simple languages into the scripting env easy, and thus accessible for beginners and students.

I gather from your comment that what you want is a "cook book" approach rather the some high-level overview. Maybe, these links can help. Probably the easiest way to get quickly up and running is to use the script control instead of connecting to a script engine directly. Check out this link as well:

BTW, while I've referred jokingly to .NET, it will change how stuff like this is done on the Windows platform

Still, the script control looks so easy to use, it is worth a more detailed look.

I gather from your comment that what you want is a "cook book" approach rather the some high-level overview.

Well, I was thinking of a pragraph of high level intro, talking about the architecture but leaving the COM interface details, followed by cookbook or example based tutorial. The end result should be something you can execute: a mini language that how one command, or some such.

I've been reading the (very good) references you gave me. But now I wonder. GetNamedItem/GetItemInfo are used to expose the client namespace, right?

It just seems that this only works when the variable appears in to context of message disptach: bob.Set(5).

So this adds insult to injury: you must use the object-model approach (this I knew, and I can live with) AND all client varaible access must be done following this approach.

But now, I am wondering. If we are writing our own scripting language, we decide what constitutes a disptaching call.

So if I am correct, the problem is as I first understood it. The [A1] hack was to overcome the syntax of VBA, so that the engine (VBA) would know it has to use the IDispatch thingy. It is not that the Windows Scripting architecture doesn't supply access to the client namespace.

To be more specific: You could implement an engine that would try to look up every variable name not found in its symbol table in the client namespace.

With regard to writing a script engine you may find this link interesting:

As to the lookup issue, yes you are correct. The IDispatch interface, which is at the root of COM Automation (the technology that enables scripting on Windows) is basically a lookup service. IDispatch::GetIDsOfNames is used to obtain the id for a named identifier, and IDispatch::Invoke is used to access it.

My initial response about lookups had to do with replacing the whole variable lookup scheme for a language, which has to deal with issues such as scoping, and which is therefore more complex. But, after some thought, it has occured to me that your initial idea about simply having the hosting application resolve unknown identifiers is actually quit doable with the MS script interfaces. While the lookup is indeed object-based, you can setup an object to be the global default. That is, any indetifier that isn't otherwise resolved, is sent to it. An example of this is the 'window' object for script hosted in a browser.

Another BTW, most COM programmers that use IDispatch do not implement the lookup code themselves. Instead they rely on the lookup services provided by COM's (minimal) reflection API. Only objects that are generated dynamically (such as script objects :) require custom implementations of this interface (or even the somewhat obscure and mostly undocumented IDispatchEx.)

But seriously (?) every non-trivial interface is ugly by definition. What I mean is that these interfaces are required to support myriad script engines and hosts. It is therefore to be expected that they would be complex, and thus ugly. What I find a bit disconcerting is that every host (all but one from Microsoft) initializes the host differently (the script engine state). At the very least this implies ambiguity in the contract between hosts and engines, as expressed by the interfaces.

Also, while I understand the need for a Close() method, I don't like it. It's something that can be easily overlooked (from experience), and if you do, some script engines crash, and some don't.

BTW, if by ugly you are also referring to IDispatch, I tend to agree. But I'd refer to it as "totally uncalled for" rather than ugly.