Different semantics can be approached by several different methods though - one can simulate an interpreter for a "guest" language in a host language - or the languages can provide an FFI for interoperability. While we have various means to combine the two different semantics of a language, we have no means to combine their syntax without encountering ambiguity problems. This is why storing code in a structured format rather than plain text could be so valuable, because it would enable us to mix and match languages in whatever way we wanted - rather than resorting to putting code inside strings, loading up new files, or complicating the syntax of our language to provide the expressivity we would like (eg, LINQ).
Diekmann and Tratt have a theory of Language Boxes[0][1] which provide the groundwork for achieving this kind of editing. They enable language quotation without the need for introducing per-language delimiters, the need to quote code in strings, and the need for escaping characters when hosting one language inside another. The editor is aware of where the language boundaries occur because they are specified by the programmer. The semantics of hosting one language in another are left up to the programmer to specify.
Composing a larger program, by combining functions in different languages in a new framework, seems to take things in the direction of large and complicated programs. Would it not be simpler to write smaller, independent, individually named and reusable programs in several languages, according to each language's strengths, and pipe the output from one of these programs to the other? As an added bonus not all the programs need to understand the entire problem domain.
This line of thinking ignores simple domain specific languages like SQL, which 9 times out of 10 are held in strings in the host language (and thus undergo no static checking because the contents of strings are basically ignored by the compiler. There are other examples too: html files contain nested Javascript, CSS etc. PHP files host HTML. C++ effectively hosts C and assembly.
Haskell hosts a few dozen languages called "extensions" - specified in a {-# LANGUAGE #-} pragma at the top of the file. This one is of particular interest because the language appears to have some kind of extensible syntax which allows these extensions to occur - except when you look under the surface, they're all combined into the same grammar and they all interact with each other, such that other extension developers basically need an entire understanding of all of them to know where conflicts may lie.
Using a framework like LanguageBoxes instead to host these kinds of extensions would allow individual developers to put their own, independant extensions into the language, without having to hack on the compiler and rebuild it.
Also, writing several independant programs and using any IPC to communicate between them is ideal in theory, but in practice is more often unsuitable - because Unix processes are a bloat. They take time to initialize and use lots more memory than necessary for what amounts to running code for a small amount of time and discarding of it. Perhaps if we had a more lightweight model of processes ala Erlang style, this kind of reusability would be practical and not just a good philosophy to follow.
Diekmann and Tratt have a theory of Language Boxes[0][1] which provide the groundwork for achieving this kind of editing. They enable language quotation without the need for introducing per-language delimiters, the need to quote code in strings, and the need for escaping characters when hosting one language inside another. The editor is aware of where the language boundaries occur because they are specified by the programmer. The semantics of hosting one language in another are left up to the programmer to specify.
[0]:http://lukasdiekmann.com/pubs/diekmann_tratt__parsing_compos...
[1]:http://soft-dev.org/pubs/html/diekmann_tratt__eco_a_language...