ANNOUNCE: lhs2tex-1.9
lhs2TeX version 1.9 =================== We are pleased to announce the first official release of lhs2TeX, a preprocessor to generate LaTeX code from literate Haskell sources. lhs2TeX includes the following features: * Different styles to process your source file: for instance, "tt" style uses a monospaced font for the code while still allowing you to highlight keywords etc, whereas "poly" style uses proportional fonts for identifiers, handles indentation nicely, is able to replace binary operators by mathematical symbols and take care of complex horizontal alignments. * Formatting directives, which let you customize the way certain tokens in the source code should appear in the processed output. * A liberal parser that can handle most of the language extensions; you don't have to restrict yourself to Haskell 98. * Preprocessor-style conditionals that allow you to generate different versions of a document from a single source file (for instance, a paper and a presentation). * Active documents: you can use Haskell to generate parts of the document (useful for papers on Haskell). * A manual explaining all the important aspects of lhs2TeX. Changes ------- Although development on lhs2TeX has begun as early as 1997, it has never been formally released before. This is a first release that should be mostly compatible to versions that have been inofficially distributed so far. It should compile with the latest GHC versions. Two completely new modes have been added compared to previous versions: "poly" mode is designed to replace the old math mode; the restriction of having only one alignment column per code block is lifted and replaced by a generic mechanism that allows complex layouts; "newcode" is a replacement for the old "code" mode that can handle formatting directives and produces LINE pragmas in the generated code. Requirements and Download ------------------------- A source distribution that should be suitable for Unix-based environments is available from http://www.cs.uu.nl/~andres/lhs2tex/ It has been verified to build on Linux and MacOSX. You need a recent version of GHC (5.04.X or higher should do) to build lhs2TeX, and, of course, you need a TeX distribution to make use of lhs2TeX's output. The program includes a configuration that is suitable for use with LaTeX. In theory, there should be no problem to generate code for other TeX flavors, such as plainTeX or ConTeXt. Happy lhs2TeXing, Ralf Hinze and Andres Loeh ralf@informatik.uni-bonn.de lhs2TeX@andres-loeh.de
In theory, there should be no problem to generate code for other TeX flavors, such as plainTeX or ConTeXt.
Any plan to maybe add support for ConteXt?
Not now. Maybe in half a year or so. I am using ConTeXt for some things, so sooner or later it would be nice to support it. If you don't want poly style (i.e. only math), it's only the matter of writing some directives which is not hard -- I think I even have an experimental .fmt file lying around somewhere. But poly style depends on polytable.sty, and this package has to be translated into a ConTeXt module, which should be possible, but would take more time, unfortunately, than I have right now. Sorry. Of course, you're welcome to try yourself. Patches are welcome. Best, Andres
Andres Loeh wrote:
[...] We are pleased to announce the first official release of lhs2TeX, a preprocessor to generate LaTeX code from literate Haskell sources.
Thanks for producing such a wonderful and useful tool! I am pleased to report that I managed to get lhs2TeX working on Win32, by modifying just a single byte in the source code. Unfortunately my "one byte patch" is just a short-term non-portable fix, and it's not entirely clear what the right long-term solution is. I thought I'd share my fix for the benefit of brave souls that wish to apply it, and offer some thoughts about what a better long-term solution might be. The Issue --------- Using Cygwin on Win32, one can build and install lhs2TeX by just following the standard build instructions given for building on Unix-like systems: ./configure ; make ; make install However, when you actually run the lhs2TeX binary installed in /usr/local/bin, it will be unable to locate its lhs2TeX.fmt file, even if you attempt to set the LHS2TEX environment variable to point to the directory where this file is installed. There are two reasons for this: 1. GHC does not use Cygwin, and produces executables that do not use the Cygwin library or understand Cygwin-style file paths. So even though "make install" installed lhs2TeX.fmt in /usr/local/share/lhs2TeX, and even though lhs2Tex attempts to open the file "/usr/local/share/lhs2TeX/lhs2TeX.sty", this path ultimately just gets passed on unprocessed to the Win32 file open function (CreateFile). Unfortunately, this is not a valid Win32 path. 2. lhs2TeX includes its own code to look for its needed files on a search path constructed from some combination of a compiled-in list of directories and those constructed from the $LHS2TEX and $HOME environment variables. This code supports both ':' and ';' as path component seperators, probably in an attempt at portability. Unfortunately, this isn't actually the right solution, as it precludes specifying drive letters in paths. A value of "C:/foo/lhs2TeX/" for $LHS2TEX ends up being processed as two directories: "C" and "/foo/lhs2TeX/"! My Quick Fix Workaround: ------------------------ 1. In the lhs2TeX sources, change line 42 of FileNameUtils.lhs from: > environmentSeparators = ";:" to: > environmentSeparators = ";" and do another "make install". 2. Set your LHS2TEX environment variable to a path that reflects where doing "make install" under Cygwin actually installed the lhs2Tex.fmt file. On my system, this is "c:/cygwin/usr/local/share/lhs2tex". Of course, this solution isn't a very good one for the long term, since ':' is the right choice for a path seperator under Unix. Thoughts on a Robust Solution: ------------------------------ As discussed above, we are really being bitten by two seperate issues here. The first is that GHC does not use Cygwin, and the second is that, in the absence of a portable infrastructure for locating files, lhs2TeX implements this itself, in an unfortunately non-portable way. The GHC team put a great deal of effort into making ghc independent of Cygwin, so I won't even bother trying to make the case for ghc just using Cygwin for file I/O (even though I think there is a strong case to be made). Instead, I propose that it would be very valuable if there were some standardized, portable library that Haskell programs like lhs2TeX could use for locating files that should be installed with the program. Ideally, such a library would support some notion of search paths, be configurable through both global and application-specific search path environment variables, and completely isolate the application from operating system-specific path name issues such as ';' vs. ':' and '/' vs. '\'. It's important that this implementation be standardized and shipped with the Haskell compiler, so that the O.S.-dependent path and internal field seperators are defined internally when the Haskell compiler is built for a particular platform, and isn't exposed to applications. This should be pretty straightforward to implement; I'm sorry I can't spare the day or so it would take to contribute this myself right now, but perhaps some enterprising soul on this list will be inspired to take a stab at it. -antony -- Antony Courtney Grad. Student, Dept. of Computer Science, Yale University antony@apocalypse.org http://www.apocalypse.org/pub/u/antony
Antony Courtney wrote:
[...]1. GHC does not use Cygwin, and produces executables that do not use the Cygwin library or understand Cygwin-style file paths. [...]
Just a note: Problems like this is exactly the reason why GHC's and Hugs' configuration scripts contain monstrosities like: # Check to see if cygpath exists. If so, use it. cygpath -w a >/dev/null 2>&1 && FPTOOLS=`cygpath -w $FPTOOLS | sed -e 's@\\\\@/@g'` Not nice, but works... Cheers, S.
Thanks for producing such a wonderful and useful tool!
Nice to hear that you find it useful. Thank you very much for sharing your results.
I am pleased to report that I managed to get lhs2TeX working on Win32, by modifying just a single byte in the source code.
1. In the lhs2TeX sources, change line 42 of FileNameUtils.lhs from: > environmentSeparators = ";:" to: > environmentSeparators = ";" and do another "make install".
Yes, that's a good fix for Windows. Actually, I copied this code from Generic-Haskell, and simplified it because I only needed it for Unix and did not have time to test it under Windows anyway. For the next release, I will try to merge the full Generic-Haskell library, which defines "environmentSeparators" and a few other functions in several "OSSpecific.hs" files, one of which can, depending on architecture, be included by lhs2TeX.
Instead, I propose that it would be very valuable if there were some standardized, portable library that Haskell programs like lhs2TeX could use for locating files that should be installed with the program. [...]
I agree on all that. I even think that there probably are several projects that have done most of that already, and that it would just be necessary to collect some source code and streamline the interface. I like the Python interface, BTW. It seems simple and pragmatic enough. Thanks again. Andres
participants (4)
-
Andres Loeh -
Antony Courtney -
Gour -
Sven Panne