[Haskell-cafe] Literate haskell format unclear (implementation and specification inconsistencies)

[Isaac Dupree]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Douglas Philips wrote:
> 
> On 2007 Mar 3, at 7:43 AM, Ross Paterson indited:
>>> but oddly doesn't seem to have been clarified in the report. We should
>>> definitely make sure that Haskell' does so!
>>
>> Or perhaps we should get rid of \begin{code} and \end{code}, before
>> someone proposes <code> and </code>.
> 
> UGH.
> 
> Since the "text" that is not inside of the \begin{code} and \end{code}
> is relatively unconstrained, would be it cool, or egregious, to have a
> comment which would permit a particular file to designate its own
> literacy boundaries?

Here's an idea:

A literate haskell file in TeX style has extension ".hs.tex".  That way
tools that recognize the .tex extension can process it as that directly,
and tools that want to "decode" it remove the .tex part of the extension
(analogous to ".gz" (compressed files), perhaps?)

So if someone really wanted, they could define a .hs.xml format and
decoder, or something (though, considering the issues of escaping
characters, '<' and '&' here, it would probably be a mess, use <![CDATA[
or something...)

Of course that leaves the question of what to call bird-style (".lhs"?
".hs.bird"??), and probably ".lhs" must remain defined as either of the
two existing styles, at the least for backwards compatibility.

Thinking about this... maybe tools like DrIFT don't need to understand
how to _create_ literate code (with the right indentation, for layout!),
if it is just as good to output plain .hs for compilers' usage...

Then we can have ordered extensions like .hs.drift.pp.tex for a file
that should be unliterated, then passed through cpp, then drift, then
*hc ^_^. And any tool that supported mutually dependent files including
its type (e.g. if DrIFT supported recursively dependent modules) would
have to be intelligent about it.

Isaac
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFF7dl6HgcxvIWYTTURAu1TAKCeZVGxGNvKqz79mCmV2m1KYtDnhwCfeCYq
9HVxhNtwxJoHksr/aXu9iIE=
=+1Mp
-----END PGP SIGNATURE-----