Hello,
I have been thinking about the design of command arguments in the Oberon System, and I would be interested to hear the reasoning behind one particular choice.
When I execute something like
```
Compiler.Compile *
```
the system does not expand `*` into some representation of the marked viewer and then pass that to `Compiler.Compile`. Instead, the `Compile` procedure receives the command arguments and itself recognizes `*` and obtains the appropriate text from the marked viewer.
Similarly, with
```
Compiler.Compile ^
```
it is the command procedure itself that interprets `^` and obtains the current selection.
I find this interesting when comparing it with the Unix shell model. For example, with
```
ls *
```
the shell expands `*` first, and `ls` receives the resulting list of filenames. `ls` does not need to know that the user originally typed `*`.
So I am wondering: why was the Oberon command system designed so that conventions such as `*` and `^` are interpreted by individual commands rather than by the system or command interpreter?
It seems that system-level expansion could make commands simpler and establish a common argument mechanism: a command could receive a text/file argument without needing to know whether the user specified it by name, by `*`, by `^`, or perhaps by some future mechanism.
On the other hand, I suspect there may be a reason why this would not fit the Oberon model. Perhaps `*` and `^` are intentionally not "argument expansion" at all, but ways for a command to interact with the state of the user interface, and therefore their interpretation belongs to the command.
Was this an explicit design decision? And are there advantages to having commands interpret these conventions themselves rather than putting such interpretation into the command execution mechanism?
I would be very interested in how people familiar with the Oberon system design think about this distinction.
Thank you,
norayr
