> 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 libr
> > Glynn Clements wrote:
> >> What Unicode support?
>
> >> Simply claiming that values of type Char are Unicode characters
> >> doesn't make it so.
Well, *claiming* so doesn't make it so. But actually representing
characters in such a way that the Unicode conformance rules are
followed, makes it
nform to LIA would be to add a
> library providing all
> the operations. The default ops (i.e., the Prelude) would
> still not conform
> to LIA but that may not be such a big deal.
It is the intent for LIA-1 that most programming languages (and their
implementations) should be a
This is getting a bit off-topic for Haskell...
> Isn't it fairly common to use 32bit Unicode character types in C?
Yes, in some implementations, but nobody by a few Linux and SunOS
programmers use that... (Those systems are far from committed to
Unicode.)
In some other systems wchar_t is (exc
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On
> Behalf Of Wolfgang Jeltsch
> Sent: den 5 januari 2002 13:04
> To: The Haskell Mailing List
> Subject: Unicode again
>
>
> Hello,
> there was some discussion about Unicode and the Char type
> some time ago. A
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 inte
> > "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 greate
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
- Original Message -
From: "Colin Paul Adams"
...
> But this seems to assume there is a one-to-one mapping of upper-case
> to lower-case equivalent, and vice-versa. Apparently this is not
> so.
True. It's quite tricky. See below.
> It seems that whilst the Unicode database's definit
xact). That is not the case for the abovementioned operations. But
it is the case for the relationship between the complex sin operation and the
complex sinh operation, for instance. (Complex will be covered by LIA-3.)
Kind regards
/Kent Karlsson
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
- 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, 20
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 t
- 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 s
- 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 ha
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 point
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 lea
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
ouble
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/under
Lennart writes:
> Is the following legal Haskell? (I'm sure I've asked this
> before, but i don't think there was a consensus.)
>
> f x = g x
> where g y = case y of
> [] -> 0
>
> The problem is that after where a '{' is inserted and another after of.
> The report now says that
> 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
> > 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 m
> 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 fin
More strange questions on what should/shouldn't happen when hiding Prelude:
Assume that (appropriate parts of) the Prelude is hidden using
import Prelude ()
or
import Prelude hiding (...something that hides (+) and/or (-)...)
or
import Prelude (...something that doesn'
Some more questions concerning some constructs in Haskell:
What if (the appropriate parts of) the standard prelude is
explicitly *not* imported:
import Prelude ()
or
import Prelude hiding(map)
(see section 5.4.3).
Are then the hidden parts of the standard prelude still a
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.)
26 matches
Mail list logo
