Of Scripting Languages and Language Engines

Scripting language - a communication tool for of telling objects on a computer what to do. You may ask: "What objects?" and I would answer: "Objects you see on the screen or objects you know are there."

"How does the computer know, what objects I mean?"

"You name them."

"Will the computer understant if I would like to do something with object I call 'document'?"

"Usualy yes - if the developer of the application would name the object you can think of as of 'document' by the same name"

"If we both agree on the name, then I can just use it in my script, right?"

"Yes. "

Now we see, that the language and scripting is about two main things: communication system (tool) and objects the tool is working with. In other words, the system is put into a small world called scripting context. It is the same with our natural language where we are allways in some context: office, restaurant, opera or disco. If I am in context 'office' and I will talk about object named 'table', then it would be obvious what table I mean by default - it would be the office table, not the table down in the cantine. The context links object names to real entities.

The language is represented by an engine (interpreter) that interprets scripts. As interpretation of all scripts is done in a context, the engine should take that fact into account. How? Primarily by consulting the context for object names. That means that when an object name (also can be called identifier, variable, constant...) is found in a script, the engine should bind it to real object through the contex.

To sum it up: there are two sides where context is considered and they are an application and a language. The application is context provider and the language is context user. While the application is responsible for giving object names that a user would expect to be, the language is responsible for resolving names in scripts to the same objects that applocation defines.

Language Manager

Language Manager was added to StepTalk. This new class allows easier language and language bundle handling. Main functionality of the class is:

• maintain list of available languages
• provide language engines and language information
• handle language registration and removal
• maintain a map of file type to language associations

This addition obsoletes old STLanguage class, several STEngine methods and the stupdate_languages tool.

What needs to be improved is StepTalk method interpretation either of the methods themselves or of the methods in an actor. One possibility is to cache engine class after first method execution.

Prototype with the language manager addition can be found here.

Remote scripting

Prototype of shared semi-persistant environments is done. With this addition the remote scripting is reality:
For more information see small presentation here (PDF document). You can download the prototype here (306kb .tar.gz).

Environments

I have started working on StepTalk semi-persistent environments. By semi-persistent I mean, that they are persistent from point of view of processes. On the other hand, the environments being processes themselves, they are destroyed between computer restarts.

Scripting environment, as mentioned, is a process of the stenvironment tool. The process creates a scripting environment object and wraps it in a Distributed Objects (DO) server that represents the process. To "talk" inside the environment, one has to create a distant conversation (STDistantConversation) with the named server.

To get better picture, very simplified analogy is a database server (= scripting environment), database connection (= conversation) and a SQL script (= StepTalk script).

Actors

New class for actors was added to StepTalk. What are actors in this context? They are objects with own attributes and methods written in a script. One can use actors for example for:

• fast prototyping of objects
• user-customisable objects or assistants
• application extensions

Each actor has to be "put into an environment" - programmatically it means that one has to assign an environment to the actor.

Here is a short example written in Smalltalk, easily rewritable to Objective-C. First we create an actor:

actor := STActor actorInEnvironment:Environment.

Then we create attributes (instance variables):

ivars := NSMutableDictionary dictionary.
ivars setObject:1 forKey:'number'.
actor setInstanceVariables:ivars.

Now, to create a behaviour, one has convert scripts into a methods. This conversion is done using an engine. Therefore we need to get the proper engine for a language of our choice, which is Smalltalk at this time:

engine := STEngine engineForLanguageWithName:'Smalltalk'.

Create a new method script:

source := 'increment number := number + 1. ^self'.

Create method and add it to the actor

method := engine methodFromSource:source forReceiver:actor inEnvironment:Environment.
actor addMethod:method.

Add few other methods in a similary way: setNumber: - set value of i; print - print i on Transcript.

Finally send the messages and see it work:

actor print.
actor increment.
actor print.
actor setNumber:10.
actor print.

Script for this example can be found in StepTalk sources Examples/Smalltalk/actor.st

StepTalk introduction

StepTalk introduction document was published and can be found here. I hope to create more documentation about StepTalk.