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).
This sort of thing is already touched upon in Arc thanks to aw's Python and Perl generators. It's also the way HTML-and-JavaScript generators work, but they do it by necessity, whereas I like the idea of code generation as a pervasive design strategy.
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.
"A cross compiler is a compiler capable of creating executable code for a platform other than the one on which the compiler is run."
http://en.wikipedia.org/wiki/Cross_compiler
"These customizable languages would instead run on a platform whose implementation doesn't matter."
That sounds like a virtual machine - the interface is fixed but you don't know or care if your code will be interpreted or JIT compiled. Am I understanding you correctly?
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. :)
By the idea of a language "targeting" a platform, all I mean is for that language to be good for developing that platform's programs. For instance, a DSL in Arc might be better for writing JavaScript than JavaScript itself is, if only because of syntax differences. Generating a bit of code using that DSL is a good way for Arc to "target" JavaScript, but it isn't the same thing as compiling a whole Arc program into JavaScript.
However, given that DSL, it would be reasonable to develop JavaScript applications using nothing but the DSL, with just enough Arc code to handle importing the DSL library and outputting the resulting files. In this case, arguably, "the whole thing" is cross-compiled to JavaScript, with the DSL library acting as that that cross compiler. When doing this kind of programming, it's irrelevant whether Arc itself is a language with a cross compiler, 'cause we only need to run Arc on one machine, the development machine we're using to produce the JavaScript code.
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.)
