I thought that could be confusing. XD In terms I was already using, what I mean is just a language that targets a platform other than its own runtime. I might have mentioned the language acting more like a compiler than a direct workhorse.
In fact, I expect that to be the way day-by-day scripting is done too; a seemingly direct syntax will instead accomplish its task by compiling itself to some better-equipped language and running that (in a separate process, for instance).
Isn't that the same as a language with a cross-compiler? Shouldn't the design of the language be independent of the design of the implementation? Or is the language designed to be easy to cross-compile? To a specific platform?
Isn't that the same as a language with a cross-compiler?
No and yes.
First, the no: A cross-compiler typically takes code designed to run on a specific language runtime and translates it to run on a different platform. These customizable languages would instead run on a platform whose implementation doesn't matter, and their libraries would let you generate programs to run on the platforms that do matter to you.
The yes is that many of the customizable language's code generation libraries are bound to actually be cross-compilers, since it's a natural way to introduce or improve support for several platforms at once. They might even let you compile certain abstractions to both the customizable language's runtime and a platform you're targeting, letting you use them both as part of the build and as part of the product. (Unit testing comes to mind.)
Furthermore, you can think of the customizable language's runtime as being its compiler, with all the language code just acting to extend it. This suggests the language's compiler targets whatever platform you tell it how to target, making it inherently a cross-compiler.
Shouldn't the design of the language be independent of the design of the implementation? Or is the language designed to be easy to cross-compile? To a specific platform?
Well... those are hard questions to interpret for this kind of language. XD I think each could answer those questions in its own way.
That said, I think the languages' built-in syntax and semantics should be reasonably extensible when that makes sense, so that fewer libraries need to be full compilers and more can just be extensions of a standard compiler. That probably has the side effects of exposing more implementation details than usual and making the language easy to cross-compile.
Come to think of it, there are some easier answers:
Should the implementation be hidden? When in doubt, no; don't make an arbitrary choice that'll disable future programmers who know better than we do.
Should we be talking about a specific platform? Not in general. :-p I recommend for the language to be designed together with its own standard language runtime platform, for interoperability's sake, but the point is for it to focus on targeting whatever platform you need it to target.
"A cross-compiler typically takes code designed to run on a specific language runtime and translates it to run on a different platform."
I don't think that's a cross compiler. All compilers translate, and I don't know what you mean by 'code designed for a specific runtime'. I think a cross compiler is concerned with the native target platform.
Nope, you're not understanding me yet. XD I think the root of it is that when you ask whether a language that "targets a platform other than its runtime" is "the same as a language with a cross-compiler," you're misinterpreting what I mean by "target." Possibly "platform" too.
As for "platform," if there's something that's nontrivially programmable, I consider it to be a platform. The thing that establishes the identity of a platform is the range of programs that's possible staying within its own practical limitations and following its rules. Adding rules lets you make platforms that embody the features several platforms have in common, as when developing for multiple Web browsers. One platform can be a program running in another (like Arc in Racket), which means its space of possible programs is no bigger than its host's, but it may also have fewer limitations and rules than its host, thanks to new frameworks it introduces and new ways it implements its host's features. A platform can be another platform with extra assumptions made about its state, like the assumption that a particular other process is available to communicate with. This is a bit of a digression, and I'm sure I haven't found all the kinds of platform families, but I'll leave it here 'cause it's thought-provoking. :)
But that kind of programming is exactly what the languages I'm talking about would focus on. The libraries would be syntax tools and compilers, and the applications would be written in mashed up DSLs. The techniques would apply to all these languages, regardless of how each of them was built internally.
(The techniques also apply to other existing languages, but the difference is that I think those languages have overall designs and philosophies that don't play well with this coding style.)