now 134
roman=(!6);n!a|n1=|n=t=s!!a:(n-t)!a|c=t=s!!(2*e):c!a|10=n!(a-1)where(d,m)=a`divMod`2;e=d+m-1;s=ivxlcdm;c=10^e+n;t=10^d*(1+4*m)
Gosh!
Anyway, you missed the roman symbols for 5000 (U+2181) and
1 (U+2182)... ;-) The ones for 5 and 10 aren't in
Unicode yet, nor is the canopy
GHC 6.2 (shortly to be released) also supports toUpper, toLower, and
the
character predicates isUpper, isLower etc. on the full Unicode
character
set.
There is one caveat: the implementation is based on the C library's
towupper() and so on, so the support is only as good as the C library
.
It is the intent for LIA-1 that most programming languages (and their
implementations) should be able to conform to LIA-1 without too much
trouble. Even if it means terminate on error in a conforming mode of
operation.
/Kent Karlsson
(Current editor of the LIA series of standards
Let me try again:
greatest - maximum/supremum of a set of integers (plain everyday order)
common - intersection (plain everyday intersection of sets)
divisor (of an integer value v) -
an integer value m, such that v/m is defined and, if so, is an
Simon == Simon Peyton-Jones [EMAIL PROTECTED] writes:
Simon Christoph does not like this
I still don't like this. 0 has never, and will never, divide anything,
in particular not 0. 0 may be a prime factor of 0 (see also below!),
but that is different. It is not the greatest (in the
I don't think preorders of any kind should be involved here.
Just the ordinary order on integers. No divisibility preorder (I'm not
sure how that is even defined, so how it could be natural beats me), no
absolute value.
I find the unaltered text Simon quoted to be fine as is.
But for those who
by LIA-3.)
Kind regards
/Kent Karlsson
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
Just to clear up any misunderstanding:
- Original Message -
From: Ashley Yakeley [EMAIL PROTECTED]
To: Haskell List [EMAIL PROTECTED]
Sent: Monday, October 01, 2001 12:36 AM
Subject: Re: Unicode support
At 2001-09-30 07:29, Marcin 'Qrczak' Kowalczyk wrote:
Some time ago the Unicode
- Original Message -
From: Ashley Yakeley [EMAIL PROTECTED]
To: Kent Karlsson [EMAIL PROTECTED]; Haskell List [EMAIL PROTECTED];
Libraries for Haskell List
[EMAIL PROTECTED]
Sent: Tuesday, October 09, 2001 12:27 PM
Subject: Re: Unicode support
At 2001-10-09 02:58, Kent Karlsson wrote
- Original Message -
From: Ketil Malde [EMAIL PROTECTED]
...
for a long time. 16 bit unicode should be gotten rid of, being the worst
of both worlds, non backwards compatable with ascii, endianness issues
and no constant length encoding utf8 externally and utf32 when
worknig
- Original Message -
From: Ketil Malde [EMAIL PROTECTED]
To: Dylan Thurston [EMAIL PROTECTED]
Cc: Andrew J Bromage [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]
Sent: Monday, October 08, 2001 9:02 AM
Subject: Re: UniCode
(The spelling is 'Unicode' (and none other).)
Dylan
- Original Message -
From: Wolfgang Jeltsch [EMAIL PROTECTED]
To: The Haskell Mailing List [EMAIL PROTECTED]
Sent: Thursday, October 04, 2001 8:47 PM
Subject: Re: Unicode support
On Sunday, 30 September 2001 20:01, John Meacham wrote:
sorry for the me too post, but this has been a
- Original Message -
From: Dylan Thurston [EMAIL PROTECTED]
To: John Meacham [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Friday, October 05, 2001 5:47 PM
Subject: Re: Unicode support
On Sun, Sep 30, 2001 at 11:01:38AM -0700, John Meacham wrote:
seeing as how the haskell standard is
- Original Message -
From: Dylan Thurston [EMAIL PROTECTED]
To: Andrew J Bromage [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Friday, October 05, 2001 6:00 PM
Subject: Re: UniCode
On Fri, Oct 05, 2001 at 11:23:50PM +1000, Andrew J Bromage wrote:
G'day all.
On
Hi!
1. I don't seem to get my messages to this list
echoed back to me... (Which I consider a bug.)
2. As I tried to explain in detail in my previous message,
(later) options 1 and 2 **do not make any sense**.
Option 3 makes at
Let me reiterate:
Unicode is ***NOT*** a glyph encoding!
Unicode is ***NOT*** a glyph encoding!
and never will be. The same character can be displayed as
a variety of glyphs, depending not only of the font/style,
but also, and this is the important
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
ve trouble
with...)
/Kent Karlsson
Dave Tweed wrote:
agree. Surely the best idea is to do something equivalent to the IEEE
floating point standard which defines certain returned bit patterns to
mean `over/underflow occu
Dear people interested in Haskell 1.3,
Disclaimer: I'm *not* a member of any "Haskell 1.3" committee,
if any such committee has been formed.
One modest extension we could make to the Haskell type system is
to permit polymorphic recursion if
a type signature is provided
I
Patterns and
expressions can look very much alike. Could one possibly expand "exp" to
"if exp" in Haskell 1.3 list comprehensions? Only to make deterministic
parsing easier...
One should not make the parsing method too
On the other hand, I think that the pat=expr syntax was something of a
design error and it may not be supported in future releases. Judging from
email that I've received, the similarity of == and = does cause confusion.
In fact, it has also caught me on at least one occassion! (So yes,
Oops, PreludeCore cannot be hidden. I guess I've made a fool of myself
(but that happens often :-).
Can't we find anything more interesting to discuss that the syntax??
You are welcome to! :-) But sweeping syntax matters under the carpet
does not improve anything.
| ... But what I find
Thanks Joe! I still don't know why anyone would want
the 'divTruncateRem' function and its derivatives, but ok,
leave them there. Why not add division with "rounding"
AWAY from zero as well. :-)
/kent k
(I've sent some detail comments directly to Joe.)
23 matches
Mail list logo
