Hi, Mauricio. Since LaTeX reserves inverted slashes for internal use, I cannot tamper with it.  The idea is to transfer the problem to Haskell (or Clean, or Scheme), not to LaTeX. After all, it is easier to program in Haskell, Clean or Scheme than in LaTeX. Anyway, here is what happens if I follow your suggestion: -- File tudin.hs import Htudin import IO import That main= do  outh <- openFile "tudin-G-H-C1.ghc" WriteMode;  hPutStrLn outh (acc "Hello, fa\unhbox \voidb@x \setbox \z@ \hbox {c}{\lineskiplimit -\maxdimen \unhbox \voidb@x \vtop {\baselineskip \z@skip \lineskip .25ex\everycr {}\tabskip \z@skip \halign {##\crcr \unhbox \z@ \crcr \hskip \hideskip \char 24\hskip \hideskip \crcr }}}ade!")  hClose outh;  outh <- openFile "tudin-G-H-C2.ghc" WriteMode;  hPutStrLn outh (show (fat 6))  hClose outh; As you can see, LaTeX sends its macro expansion to the Haskell file.  Another possibility is to change the classification of \ (reverse slash). Here is how to do it: \catcode`\\=11 Now the reverse slash is a normal char. Of course, I need to change the classification of every accent, tilde, cedil, umlaut, etc. I cannot change the grave, because I need it to make the change itself. Users don't like this kind of solution. In any case, here are the programs with the characters modified (I will post a more complete library in my site; then I will add a few graphical functions so people can understand the problem). Compilation is as before: 1 --- C:\hastex>  latex tudin.tex 2 --- C:\hastex> runghc tudin.hs 3 --- C:\hastex> latex tudin.tex It is possible to use pdflatex instead of latex. By the way, Haskell cannot print your name, since it has an acute i :-) It would be great if people could solve this problem. % Store in file hask.ell % Last change 2007-05-23 \newcount\evalFilecount \evalFilecount=0 {\gdef\evalSetup{%   \csname newwrite\endcsname\outPort % Port name   \immediate\openout\outPort \jobname.hs %   \newlinechar=`\^^M%   \immediate\write\outPort{import H\jobname}%    \newlinechar=`\^^M%   \immediate\write\outPort{import IO}%    \newlinechar=`\^^M%   \immediate\write\outPort{main= do  }%   \newlinechar=`\^^M% }% } \newcommand{\eval}{\begingroup   \ifx\outPort\UNDEFINED \evalSetup\fi   \global\advance\evalFilecount by 1   \edef\evalAuxFile{\jobname-G-H-C\the\evalFilecount}%   \immediate\write\outPort     {  outh <- openFile "\evalAuxFile.ghc" { WriteMode;} }%   {\immediate\openin0=\evalAuxFile.ghc    \ifeof0 \immediate\closein0    \else \input \evalAuxFile.ghc \fi}%   \catcode`\^^M=12   \catcode`\\=11   \catcode`\~=11   \catcode`\'=11   \catcode`\`=11   \catcode`\^=11   \evalBody  } \newcommand{\evalBody}[1]{%   \immediate\write\outPort{#1}%   \immediate\write\outPort{   hClose outh;}%   \endgroup   } %end of file hask.ell % Store in file  haskell.gen % Last change 2007-05-23 \newcount\evalFilecount \evalFilecount=0 {\gdef\haskellSetup{%   \csname newwrite\endcsname\progPort   \immediate\openout\progPort H\jobname.hs %   \immediate\write\progPort{module H\jobname}%   \immediate\write\progPort{where}%   \newlinechar=`\^^M%   \newlinechar=`\^^M% }% } \newcommand{\haskell}{\begingroup   \ifx\progPort\UNDEFINED \haskellSetup\fi%   \catcode`\^^M=12   \haskellGen  } \newcommand{\haskellGen}[1]{%   \immediate\write\progPort{#1}%   \endgroup   } %end of file haskell.gen % File: tudin.tex \documentclass[12pt]{article} \usepackage[latin1]{inputenc} \usepackage[brazil]{babel} \usepackage{makeidx} \usepackage{wrapfig} \usepackage{pictexwd} \newcommand{\cc}{\c{c}} \title{Calling Haskell from \LaTeX} \author{Philippos Apolinarius} \date{} \begin{document} \maketitle \input haskell.gen \input hask.ell % load \eval \eval{ hPutStrLn outh "Hello, fa\\c cade!" } \eval{ hPutStrLn outh "Il est l\\`a bas!" } \eval{ hPutStrLn outh "Raison d' \\^etre!" } \eval{ hPutStrLn outh "Votre toast, je peux vous le rendre, Se\\~nor!" } \eval{ hPutStrLn outh (show (fat 6)) } \haskell{  fat n | n<1= 1  fat n= n*fat(n-1) } \end{document}   --- On Sat, 10/24/09, Maurí­cio CA wrote: From: Maurí­cio CA Subject: [Haskell-cafe] Re: A 3 line program --> Reid, Don, Daniel To: haskell-cafe@haskell.org Received: Saturday, October 24, 2009, 8:28 PM Philippos, Doesn't the line below means everything to be interpreted will be considered as latin1?   \usepackage[latin1]{inputenc} Unicode as UTF-8 won't fit here. I would sugest transfering the problem to latex. Why not to print 'fa\c cade' instead of 'façade'? It's 7 bits and will never fail. Best, Maurício

Thank you for your help. I am sure that you are right as to the cause of the problem.  However, I do not know what I should do to solve it. The Haskell program is generated by LaTeX macros. (...)

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe __________________________________________________________________ Looking for the perfect gift? Give the gift of Flickr! http://www.flickr.com/gift/

On Oct 26, 2009, at 20:12 , Richard O'Keefe wrote:

On Oct 25, 2009, at 5:01 PM, Curt Sampson wrote: The corresponding part of the GHC documentation says

GHC assumes that source files are ASCII or UTF-8 only, other encodings are not recognised. However, invalid UTF-8 sequences will be ignored in comments, so it is possible to use other encodings such as Latin-1, as long as the non-comment source code is ASCII only.

There's no obvious reason why GHC couldn't support any source encoding that the host's iconv() supports.

That would be the Haskell98 Report: Haskell uses the Unicode [11] character set. However, source programs are currently biased toward the ASCII character set used in earlier versions of Haskell . This syntax depends on properties of the Unicode characters as defined by the Unicode consortium. Haskell compilers are expected to make use of new versions of Unicode as they are made available. So yes, it's reasonable to "blame" the language (spec). -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH

Colin Paul Adams writes:

Brandon> So yes, it's reasonable to "blame" the language (spec).

On the other hand, the sooner users can get moving to utf-8, the sooner we can get eliminate these kinds of problems.

Note also that it mentions the Unicode character set, not a particular Unicode encoding scheme.

To me that implies that an implementation must support all 7 encoding schemes, not just UTF-8.

...but not latin1, which appeared to be the problem here.

At which point you probably want to make use of iconv, so you might as well support all iconv-supported encodings.

Interestingly, Wikipedia [0] says that "Unicode-aware programs are required to display, print and manipulate [UTF-32 and -16]", although no source is provided for this requirement. But until somebody actually has Haskell sources in a Unicode-encoding different from utf-8, I'd much prefer developers to spend their time on something more useful. (And the workaround is just one line in a Makefile, isn't it?) -k [0] http://en.wikipedia.org/wiki/Comparison_of_Unicode_encodings -- If I haven't seen further, it is by standing in the footprints of giants

In a private email to Ketil Malde, I said that Ocaml programmers use the preprocessor to solve the problem of character encoding: ocamlopt -pp myfilter.exe myprogram.ml -o myoutput.exe I wonder whether a similar solution could be used with Haskell. I am new to Haskell, but I suppose that Haskell may accept something like ghc -pgmF myfilter.exe myprogram.hs --make If the answer is yes, what should I substitute for myfilter.exe? --- On Tue, 10/27/09, Ketil Malde wrote: From: Ketil Malde Subject: Re: [Haskell-cafe] A 3 line program --> Reid, Don, Daniel To: haskell-cafe@haskell.org Received: Tuesday, October 27, 2009, 2:06 AM Colin Paul Adams writes:

     Brandon> So yes, it's reasonable to "blame" the language (spec).

On the other hand, the sooner users can get moving to utf-8, the sooner we can get eliminate these kinds of problems.

Note also that it mentions the Unicode character set, not a particular Unicode encoding scheme.

To me that implies that an implementation must support all 7 encoding schemes, not just UTF-8.

...but not latin1, which appeared to be the problem here.

At which point you probably want to make use of iconv, so you might as well support all iconv-supported encodings.

Interestingly, Wikipedia [0] says that "Unicode-aware programs are required to display, print and manipulate [UTF-32 and -16]", although no source is provided for this requirement. But until somebody actually has Haskell sources in a Unicode-encoding different from utf-8, I'd much prefer developers to spend their time on something more useful. (And the workaround is just one line in a Makefile, isn't it?) -k [0] http://en.wikipedia.org/wiki/Comparison_of_Unicode_encodings -- If I haven't seen further, it is by standing in the footprints of giants _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe __________________________________________________________________ Looking for the perfect gift? Give the gift of Flickr! http://www.flickr.com/gift/