syntax...(strings/interpolation/here docs)

[Claus Reinke]

> |  ..[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)..