So now that I've done what I could to muddy the waters, what is your intentions of the use for this language?
Well, that's part of the problem; I want something that will handle widely differing tasks. In the end, it would probably not be a single language but a family of languages with similar syntaxes and semantics, but applied to different purposes. OTOH, many systems (Smalltalk, LISP-OS, most Forth implementations) have used a single language for all purposes, and it would be desireable for this system to do so as well. Since this is part of what is probably going to be a purely experimental system, I am (trying to be) willing to make mistakes along the way if I can learn something from them.
The main needs are for a system-level language for use in developing the underlying OS, and a user-level language that is primarily for command entry and light scripting. There will probably be a need for a tools-level language between them; otherwise, the two would have to overlap their roles somewhat to cover that aspect. Obviously, this is already a huge goal.
The first overall goal is for the syntax to be minimal (as few different syntactic forms as possible), regular (things with similar semantics should have similar syntax), orthogonal (things with differing semantics should have different syntax), extensible (new syntactic structures could be added when needed) and universal (programmer objects and functions should be equal to those inherent to the language) - no suprises there, given my preferences, but no mean feat, either. Few languages achieve even one of these goals, and for good reason. All of them require judgement calls on the part of the designer, especially the questions of which structures are semantically orthogonal, and what features should be primitive rather than added through libraries. Extensibility opens up a Pandora's Box of conflicting structures which may have to work together in unexpected ways, while universality can hide important information. And since there are many - infinitely many, in theory - ways of expressing any of these concepts in an actual syntax, it doesn't help in the actual process of language design except as a kind of Occam's Razor by which extraneous features are carved away.
In the command/scripting language, a subject-verb-object or subject-object-verb grammar is desired, as exemplified by Smalltalk in the former and Forth in the latter. These have generally proven easier for users that the function (verb-subject-object) grammar more typical of command languages. While the grammar is somewhat less critical in the systems and tools languages, it should match that of the scripting language to lessen confusion.
Garbage collection will be a systems-level function, and the languages should be built with that in mind. However, since the memory management is to be implemented in the systems language, so a way of disabling or bypassing the service may be needed.
The systems language, at least, should be designed for incremental development and provide a path for transitioning from prototype to product. The scaffolding needed for rigorous implementation - secure typing, design-by-contract constraints, separation of namespaces, separate compilation into standalone executables, etc. - should be part of the language, but in such a way that they are added as the design coalesces, not as a forced limitation throughout the process. To put it simply, it should be possible to begin with a piecemeal, exploratory coding under an interpreter, and piece by piece add the requisite structural supports needed to assure a stable result, with the final level being a compiled, standalone component that has passed a battery of requirements before release. Again, this is an ideal that is probably not very reasonable, one but I still want to aim for.
As part of this, I would want the language to compile into a portable intermediate form (either a parse tree or a bytecode) which is then verified and JIT compiled on invocation (the executable code would be cached to speed up subsequent uses). A 'slim binaries'-style parse-tree approach is, IMAO, preferable over a bytecode, as it retains the high-level structure of the code and allows more fine-tuned local optimization.
For the user language, I want, first and foremost, one which can be interpreted as a single expression; the idea is that the user should be able to type in a command, select and execute it, without a program structure or explicit interpreter call - in other words, as a command line interface or shell. It should also be capable of scripting.
The tool-level language has to serve the same purposes which ELISP does in EMACS (and VBA in Office), as language for extending the user interface and building user tools and modes; since it will be used in an event-driven environment, it has to have some ability to deal with inderminant behavior on the part of the user. All UI features - clicking on an icon, selecting a section of text, typing a character - will be an action in this language.
The low-level language has to produce reasonably efficient object code - not blazingly so, with current processors, but still efficient enough that slowdowns are avoided. It should work cleanly with other languages, especially the assembly language of the machine it is on. However, it should be capable of handling high-level abstract data with ease, and support such concepts as high-order functionals (functions that generate functions), closures (or true objects, which have similar properties), and reflectivity (important for the previously mentioned GC issue). I would want to be able to mix functional and object-oriented styles, but I don't want a bias towards either one.
The last idea I want is perhaps the oddest of all: that objects/components be system level constructs, independent of the language they are written in. (Yes, I know that that is what DCOM components are supposed to be, but a single bad implementation does not make the idea itself a bad one). I actually see the objects as a kind of threaded- interpretation closure - you would pass the object a message, and it would invoke the interpreter meta-object to run itself.
So there it is: a welter of conflicting ideas that I am hoping to somehow find the common thread through, the unifying structure that will put all these conflicting goals into a single, straightforward perspective. I don't expect to succeed, but I still feel the need to try. |
