Yesterday while I was mucking around in GHCi I discovered the following
anomaly. (The same holds for compiled code.)
I typed
:t (# 2, 3 #)
and got back
(# 2, 3 #) :: forall t t1. (Num t, Num t1) = (# t, t1 #)
But when I typed
:t (# 2, 3 #) :: (# Int, Int #)
I got the following
Illegal
Sean writes:
Yesterday while I was mucking around in GHCi I discovered the following
anomaly. (The same holds for compiled code.)
I typed
:t (# 2, 3 #)
and got back
(# 2, 3 #) :: forall t t1. (Num t, Num t1) = (# t, t1 #)
But when I typed
:t (# 2, 3 #) :: (# Int, Int #)
I
Lennart Augustsson [EMAIL PROTECTED] writes:
Glynn Clements wrote:
What Unicode support?
Simply claiming that values of type Char are Unicode characters
doesn't make it so.
Just because some implementations lack toUpper etc. doesn't mean
they all do.
I think the point is that for
Am Freitag, 28. November 2003 22:21 schrieb Glynn Clements:
[...]
What do you mean with this? Hopefully, not dropping Unicode support
because this would be a very bad idea, IMHO.
What Unicode support?
Simply claiming that values of type Char are Unicode characters doesn't make
it so.
Am Freitag, 28. November 2003 08:49 schrieb John Meacham:
[...]
I also have wondered how much the string representation hurts haskell
program performance.. Something I'd like to see (perhaps a bit less drastic)
would be a String class, similar to Num so string constants would have type
[EMAIL PROTECTED] wrote:
What Unicode support?
Simply claiming that values of type Char are Unicode characters
doesn't make it so.
Just because some implementations lack toUpper etc. doesn't mean
they all do.
I think the point is that for toUpper etc to be properly Unicoded,
John Meacham wrote:
What Unicode support?
Simply claiming that values of type Char are Unicode characters
doesn't make it so.
Actually supporting Unicode would require re-implementing toUpper,
toLower and the is* functions, as well as at least re-implementing the
I/O library
Wolfgang Jeltsch wrote:
Right now, values of type Char are, in reality, ISO Latin-1 codepoints
padded out to 4 bytes per char.
No, because this would mean that you wouldn't have chars with codes greater
than 255 which is not the case with GHC.
However, the behaviour of codes greater
As a matter of pure speculation, how big an impact would it have if, in
the next version of Haskell, Strings were represented as opaque types
with appropriate functions to convert to and from [Char]? Would there be
rioting in the streets?
Andrew Bromage
I would complain. I don't care much
On Sat, Nov 29, 2003 at 11:10:57AM -0500, Wojtek Moczydlowski wrote:
(though it still bothers me that I don't have an answer yet to the
memory leak I posted some time ago)
If you are talking about StateT space leak, then I think I have given
you an answer. My guess was that it is a CAF leak.
Hi!
Calling isSymbolicLink always returns False... (ghc-6.0.1linux binary
tarball)
It doesn't make a difference whether the symbolic link points
to a regular file or a directory.
Test code:
#ln -s test link
#ghc Test.hs -o test
#./test
False
#
Test.hs:
module Main(main) where
import
You need to use getSymbolicLinkStatus instead of getFileStatus, which
always follows symbolic links (I guess getSymbolicLinkStatus uses the
stat system call, while getSymbolicLinkStatus uses lstat).
--
Sebastien
On Sat, Nov 29, 2003 at 08:24:08PM +0100, Johannes Goetz wrote:
Hi! Sorry for
In article [EMAIL PROTECTED],
Glynn Clements [EMAIL PROTECTED] wrote:
Simply claiming that values of type Char are Unicode characters
doesn't make it so.
Actually, that's exactly what makes it so.
And in article [EMAIL PROTECTED],
Glynn Clements [EMAIL PROTECTED] wrote:
Unless I'm missing
G'day all.
Quoting John Meacham [EMAIL PROTECTED]:
Something I'd like to see (perhaps a bit less
drastic) would be a String class, similar to Num so string constants
would have type
String a = a
Interesting that you mention this. I've also been thinking about this
lately in the context of
Tomasz Zielonka said:
On Thu, Nov 27, 2003 at 04:09:00PM -0300, andrew cooke wrote:
[...]
If I compile and run the code below, the file foo contains 10 lines
of output (as I would expect), but the file bar contains just 9 -
the final line is missing. If I add a join, as in the comment, then
G'day all.
Quoting Wolfgang Jeltsch [EMAIL PROTECTED]:
I think, I have already said the following on this list. I would also like to
have different character types for different subsets of Char (e.g., ASCII)
and a class Character which the different character types are instances of.
As a
Ashley Yakeley wrote:
Simply claiming that values of type Char are Unicode characters
doesn't make it so.
Actually, that's exactly what makes it so.
Hmm. I suppose that there's some validity to that perspective. OTOH,
it's one thing to state that it's true, but that's rather hollow if
On Sat, 29 Nov 2003 [EMAIL PROTECTED] wrote:
(snip)
Interesting that you mention this. I've also been thinking about this
lately in the context of the discussion on collections and the left-fold
combinator both here and on LtU. When people say I want String to be
[Char], what I'm actually
In article [EMAIL PROTECTED],
Glynn Clements [EMAIL PROTECTED] wrote:
OK; by Char is 4 bytes I basically meant that it's large enough.
Char is exactly the correct size. The Eq, Ord and Enum instances all
work correctly. The fact that you cannot represent values outside the
range is important
On Fri, Nov 28, 2003 at 04:56:02PM -0500, Mark Carroll wrote:
(shifting to Haskell-Cafe)
On Fri, 28 Nov 2003, Donald Bruce Stewart wrote:
ajb:
(snip)
As a matter of pure speculation, how big an impact would it have if, in
the next version of Haskell, Strings were represented as
At 16:56 28/11/03 -0500, Mark Carroll wrote:
(shifting to Haskell-Cafe)
On Fri, 28 Nov 2003, Donald Bruce Stewart wrote:
ajb:
(snip)
As a matter of pure speculation, how big an impact would it have if, in
the next version of Haskell, Strings were represented as opaque types
with
21 matches
Mail list logo
