You can already do something similar like this ..
10 mc=$C000 : REM machine code command address
100 CALL mc,a,b,c
My point is that (a) you don't need the explicit CALL keyword, and (b) the variable is used as a keyword. So your example would look like this:
mc = CMDPTR($C000)
The USR() function is probably one of the most ignored functions in BASIC because of it's clunky use. I've been thinking of changing it to allow the address to be passed along with the first arguament. So you could do ..
One of the reasons it's so clunky is because you do
have to keep worrying about addresses, and the fact that USR() doesn't say what the function does (except that it's a user-defined function).
...this time mc would be evaluated and, on seeing the comma, held as the execute address.
Situational logic like this is what makes BASIC the
number one most detested language in all of computer science and engineering. In no uncertain terms, BASIC is not a proper programming language. It's a collection of bandaids that lets the user do programming-related tasks. This was as true when it was first introduced back in the 60s as it is today.
I do not mean this as an insult to you, or to any BASIC programmer. It's just that having a language construct behave differently depending on whether or not a comma follows a parameter has been proven time and again to be a huge source of bugs and programmer grief.
command and function names difficult. There is also that EhBASIC, being an interpreter, tokenises all code lines before executing them so embedded keywords would get crunched inappropriately.
That's why you have new variable types to handle addresses. These become variable names, and therefore can be tokenized just like regular variable names.
When first tokenizing a line, if the unidentified keyword isn't already a command or function variable, this
is when BASIC will try to load the command into memory, and create a variable for it. (After all, BASIC auto-creates unidentified variables when you first use them!)
There's no reason why CALL and USR() couldn't be used to call the shell from within the BASIC environment but, as you say, this (the shell) is not a portable feature.
The whole point of the discussion is that BASIC **IS**
the shell. How can USR() be used to call "the shell" when it already IS the shell?
As I said, BASIC really isn't an appropriate language to do this sort of thing with. Oberon is actually built
with this kind of usage in mind (it's extremely modular). Forth requires minimal amounts of boiler-plate to do it, but the syntax of the language is so regular that it might be worth it. This is why I advocated using Forth as the basic system software: it's expected
that people will load their favorite languages from disk. 9 out of 10 people will probably not ever use that Forth environment. But for those who lose their boot-disk, or whatever, the Forth environment provides a very low-overhead, fully functional language environment that allows the computer to continue to be used productively, instead of just sitting there, repeating the message "Non-system disk. Press any key" all the time.
There's nothing quite like paying $900 for a genuine AMD Athlon or Intel Pentium IV Xeon-based, 512MB IBM PC-compatible paperweight with the latest nVidia GeForce 4 chipset video card. I don't spend $15000 for a new car, only to have to load the engine in it every time I want to use it. It comes with a perfectly good engine on its own. If I want something better, then and only then will I replace the engine.
Hmm...I'm not sure I can express this clearer, and I get the distinct feeling that I've probably offended a few people here. So I'll stop now while I'm still ahead.