I want to consider here languages for small native, key savvy, Keykos applications.
I want a language with simple as well as clean semantics.
I want a language that non-programmers can learn in a few days.
We probably need to support many popular languages but supporting
legacy apps in those languages is somewhat different from supporting
new native apps designed to be key savvy.
I shall ignore for now the significant problem of converting programmers
to new languages.
We should consider Perl, Python, Rexx and the various shell script languages to be casual programming languages which can be used for simple, quick, small applications for which performance is not paramount.
Lets consider some language attributes and consider how they fit with Keykos.
- Compiled
- Beyond the scope of this note. We must and do support compiled languages.
- Object Oriented
- Not necessary. Indeed this might be contraindicated for we would like
Keykos style modularization.
Still there may be merit in two styles at once.
- Large Scale
- By this I mean that it has features necessary for large scale code with multiple components.
Again I think that Keykos should be the primary technology for subdividing
native applications.
Languages that support OO and large scale pay something and we should not
require native programmers to learn two technologies.
- Interactive
- Yes. It should be easy to step thru a program and have a meaningful
conversation with the interpreter about the state of the computation.
This requires a simple execution model.
This presumably also allows command mode which may serve as a command language.
- Malleable Behavior
- This means that the behavior can be changed without losing the state.
This is more a property of the interpreter than of the language.
- String Oriented
- By “string oriented” I mean that expressions evaluate to strings instead
of CPU oriented things such as ints, chars, bool, etc.
I am down on string oriented languages but do not have room here to explain why. Still it may be suitable for those who know some string language.
There are three places where such code could go.
- In a domain like thing just as machine code is obeyed by domains.
- In a factory like thing, which would automatically follow from the above
if the domain like thing was sufficiently polymorphic with the domain.
- as the operand of a “source” like that of a Unix shell command.
This would be useful but dangerous.
See a note about the Command Language Interpreter.
Other considerations are that Keykos is good at building systems written in a variety of languages.
In this regard it is like Corba IDL with less conceptual overhead, I think.
Here I consider accessing keys in object languages.
A suitable shell might do.
See this about some early ideas.
The above was written approximately 1986.
It is now 2009 and I would now consider Scheme or OCaml for their clean semantics and interactive implementations.
I think neither existed in 1986 and indeed no other language with proper closures and anonymous functions as far as I know.
Programs that wield keys usually have a theory about the sorts of objects they are to.
A crude adaptation of Scheme to Keykos would leave all such issues to the code and this is indeed a vital mode to support.
Binary byte strings would be necessary and perhaps Scheme’s big integers would suffice.
You need the notion of concatenation of such strings.
A different notion of wielding keys would somehow express the theory of alleged key type in order to make the code easier to read and write, and also perhaps avoid some classes or errors thereby.
Scheme lacks a notion of method dispatch.
There are many ways to add such a notion as syntactic sugar but no such way clearly dominates the rest.
A dynamic theory of alleged types for keykos objects would presumably want some convenient sort of method dispatch for Keykos objects.