I had option 1 in mind when that part of the report was written. We
should clarify this in the next revision.
And thanks for your analysis of the problem!
John
>Carl R. Witty wrote:
>
>> 1) I assume that layout processing occurs after Unicode preprocessing;
>> otherwise, you can't even find the lexemes. If so, are all Unicode
>> characters assumed to be the same width?
The easiest way of thinking of Unicode is perhaps as a font encoding; a
font using
Carl R. Witty wrote:
> 1) I assume that layout processing occurs after Unicode preprocessing;
> otherwise, you can't even find the lexemes. If so, are all Unicode
> characters assumed to be the same width?
Unicode characters ***cannot in any way*** be considered as being of
the same display wid
Kent Karlsson <[EMAIL PROTECTED]> writes:
> Carl R. Witty wrote:
>
> > 1) I assume that layout processing occurs after Unicode preprocessing;
> > otherwise, you can't even find the lexemes. If so, are all Unicode
> > characters assumed to be the same width?
I guess I wasn't as clear as I shoul
Unicode was added at the last moment, so there is likely to
be some descrepancies.
> 1) I assume that layout processing occurs after Unicode preprocessing;
> otherwise, you can't even find the lexemes. If so, are all Unicode
> characters assumed to be the same width?
I think that's what is inte
I have some questions regarding Haskell 1.4 and Unicode. My source
materials for these questions are "The Haskell 1.4 Report" and the
files
ftp://ftp.unicode.org/Public/2.0-Update/ReadMe-2.0.14.txt
and
ftp://ftp.unicode.org/Public/2.0-Update/UnicodeData-2.0.14.txt
It's possible that questi
The Haskell Report says:
To facilitate the use of layout at the top level of a module (an
implementation may allow several modules may reside in one file), the
keyword module and the end-of-file token are assumed to occur in
column 0 (whereas normally the first column is 1). Otherwise, all
top-le
