| ..[here documents: .. old and very useful hat]..
At a time when many developers pay careful attention to internationalization ("I18n"), which requires careful separation of program text (functionality) and user text (display), a feature that instead ties them more closely together seems to be a step in the wrong direction.
Sorry? We seem to be talking cross purposes here. What triggered this suggestion was actually a question about how to *improve* support for internationalisation in Haskell. I think that functional composition can give us a rather more expressive framework for this than the usual separation of applications into code and a text database. Few applications directly allow such a separation, especially when GUIs are involved, and even fewer improve when pressed into this scheme. Rigid code, to be patched by equally rigid text fragments, loaded from some resource-controlled database, is no replacement for text that can be parameterised by the code and code that adapts to the text (e.g., during layout or because of other variations of program behaviour necessitated by localisation). Haskell already supports unicorns (cough), and as some of these have actually been sighted in Haskell implementations, the debate on what they actually look like, or should look like, is ongoing. Haskell definitely supports abstraction and composition, so we can factor out application aspects (not just text) that need localisation, and link them (dynamically?) with the main parts of our applications. Some systematic approach would be useful, but apart from keeping track of the issues raised in the standards committees, I don't see why Haskellers should limit themselves to "the" standard way of patching C#/Java apps with translated text fragments. But that's just personal opinion. As you say,
..the presence or absence of Here documents or resource bundles will not force the language in either way. But it will determine the "feel" of the language, and so have an impact on the way that it is perceived and used.
I can only see here documents facilitating string handling. Moreover, they are usually employed exactly to write text as it should be read, parameterised as necessary, but otherwise separated from the main code, and not interspersed with string construction operations. So they also help the separation you want. For what it's worth: my personal reason for wanting here documents is meta-programming in Haskell. For instance, I generate VRML scenes with embedded ECMAScript (not my choice..) from a Haskell embedding. Others generate HTML, e.g., in web server-side Haskell scripting or documentation generators, or XML, in general data processing, or Haskell code in program transformations, or C/Java/IL/IDL.. code in compilers and interface generators, or C code in C code transformations (although Galois implemented that in SML, I think), .. and so on, and so on. Haskell may not be very efficient at representing strings, but that is (a) an implementation issue and (b) hasn't hindered string processing to become one of the major application areas for Haskell. Here documents achieve at the level of strings a subset of what metaML achieves at the level of expressions. It doesn't cost much to have them, and it costs a lot not to have them - debugging program generators without them is a mess, and even with a self-made variable substitution it is unnecessarily error-prone. I'm a bit surprised that some Haskellers apparently have not experienced here documents as an entirely benign and productivity-enhancing feature. Just because it is usually found in shells and perls, that doesn't mean it wouldn't be good enough for a "real" language. But unless other Haskell application and library programmers in need of this cry out in favour, I'll grumble on in silence (hooray for Hugs, though;-). Regards, Claus PS. Unless I'm mistaken, "I18N/L10N" is a play with characters that befits the purpose rather badly: "Internationalisierung/Lokalisierung", ..(add your own translation here)..