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.