What you're describing is broadly similar to the idea of using inline assembly in C or C++, which is something games in particular used to do a lot back in the days of 16-bit DOS. As in that scenario, I would argue that the high-level and low-level aspects of the language are actually using two separate languages with different idioms and ways of approaching the problem.
Functionally, it would be quite similar, yes. But in terms of usability (for the programmer), I don't think there's much similarity... Sorry, it's hard for me to elaborate right now.
[quote name='Oberon_Command']
For what you're trying to do, not really. Consider that the objection in the OP to the idea of source code was that design and implementation should be distinct. If you're "falling back to the lower levels" to implement a particular feature, then you're blurring the line between the high- and low-levels - between the design and the implementation, which is exactly the opposite of what you're trying to enforce. If it becomes idiomatic to specify the low-level implementation for a high-level construct in any given program (and for performance-critical programs like games, it will), then idiomatically the "design" and "implementation" will not be distinct the way you want, which means that practically speaking your language will offer no advantages over the existing solutions you object to in the OP.
[/quote]
When I talk about high-level and low-level constructs, I am referring to the implementation aspect only. A high-level line of code might be "sort these numbers" while a low-level one might be the C++ code to do bubble sort.
I think it's best to compare the high-level functions to an API of a standard library, while the low-level stuff would be the implementation of said functions.
Another way to look at this might be to create an interface that allows to easily move things into a library (which is easily shared across projects/developers). Right now, creating a library involves a lot of overhead work, making it easier to simply leave any potentially-library-level code as baked into your current project, rather than extracting it for better reuse.
On another hand, I'm starting to realize that if you're really creating a general purpose program, it might be hard to separate the design from the implementation, and source code might be a good way to represent design after all. It's not the same if you're creating a real-time simulation (a game) vs. a GUI app.
P.S. Please excuse me if I'm starting to say really stupid things, as this whole thing is becoming a mess in my head and I'm working on figuring things out. Part of the problem is I had to take a break from this for a while, and by now I've forgotten the exact context of this thread (plus it probably changed direction a bit by now)...
