Jerzy Karczmarczuk wrote:
Robert Will wrote:
Why is 'last' so much slower than 'head'? Why is 'head' not called
'first'? Why does 'but_last' (aka init) copy the list, but 'but_first'
(aka tail) does not?
Are those rhetoric questions, asked just to inspire some discussion, or
you *really*
Am Dienstag, 9. Dezember 2003 18:34 schrieb Malcolm Wallace:
[...]
The most obvious is the LVM. See Helium though the LVM is not tied to it.
Both Hugs and nhc98 are also based on bytecode interpreters.
Wouldn't it be good to implement an LVM import/export feature in GHC, Hugs and
nhc98?
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
At 15:52 08/12/03 -0500, Derek Elkins wrote:
What Haskell byte code projects are out there?
The most obvious is the LVM. See Helium though the LVM is not tied to
it.
I tried to track that down (for a colleague), but the link at:
http://www.cs.uu.nl/helium/documentation.html
to:
On Tue, 09 Dec 2003 10:51:08 +
Graham Klyne [EMAIL PROTECTED] wrote:
At 15:52 08/12/03 -0500, Derek Elkins wrote:
What Haskell byte code projects are out there?
The most obvious is the LVM. See Helium though the LVM is not tied
to it.
I tried to track that down (for a colleague),
Hi Graham,
I tried to track that down (for a colleague), but the link at:
http://www.cs.uu.nl/helium/documentation.html
to:
http://www.cs.uu.nl/~daan/papers/lvm.pdf
is broken, and I can't find any other references.
Sorry for the broken link. The LVM is described in
the last chapter
On Tue, Dec 09, 2003 at 08:40:12AM -0500, Derek Elkins wrote:
I tried to track that down (for a colleague), but the link at:
http://www.cs.uu.nl/helium/documentation.html
to:
http://www.cs.uu.nl/~daan/papers/lvm.pdf
is broken, and I can't find any other references.
Yeah, it
Unless I'm missing something, the only support that GHC provides is
that Char is 4 bytes.
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
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
On Mon, Dec 08, 2003 at 01:45:30PM -, Simon Marlow wrote:
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,
Even in unoptimized, byte-code compiled code?
Take this module:
module A where
t :: IO ()
t = sequence_ (repeat (return ()))
If I :load it into ghci as interpreted, or if I compile it without
optimisation options, and I run t, then the process grows, and grows,
and
On Mon, Dec 08, 2003 at 02:24:51PM -, Simon Marlow wrote:
Just compiling the code (instead of running it in GHCi) is enough to
prevent CAFs from leaking.
Ah, I see the story is a bit different that I thought.
Please correct me I am wrong:
When I compiled the code with -O2 there was no
But then... what trick does GHC use to prevent CAF leaks?
No tricks really, the garbage collector traces references from code as
well as references from the heap to find all the live data. Of course,
it doesn't actually examine the code; each code segment comes with a
list of top-level
Am Montag, 8. Dezember 2003 15:13 schrieb Tomasz Zielonka:
[...]
Even in unoptimized, byte-code compiled code?
Does GHCi use byte code internally? Would it be possible to export this code
and load it into GHCi again or compile it to machine code? What Haskell byte
code projects are out
On Mon, 8 Dec 2003 20:59:53 +0100
Wolfgang Jeltsch [EMAIL PROTECTED] wrote:
Am Montag, 8. Dezember 2003 15:13 schrieb Tomasz Zielonka:
[...]
Even in unoptimized, byte-code compiled code?
Does GHCi use byte code internally?
Yes.
What Haskell byte code projects are out there?
The
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
On Sat, 29 Nov 2003, Graham Klyne wrote:
Following this debate, I find myself wondering if this is not something
that might be optimized behind the scenes as a common case, rather than
changing the computational model presented.
Argh, please, no! I find this kind of implicit optimisation can
Am Samstag, 29. November 2003 23:58 schrieb [EMAIL PROTECTED]:
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
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
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
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
John Meacham wrote:
[EMAIL PROTECTED] wrote:
...
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?
I also
Am Freitag, 28. November 2003 04:32 schrieb Ben Escoto:
Hi, can someone tell me why Haskell strings are linked lists?
I think they are lists because there is already good support for lists in
Haskell. You can just take the many list functions and apply them directly to
strings.
You could then
Wolfgang Jeltsch wrote:
| 1. Today I spend a few hours trying to track down a memory leak. It
| turns out I just didn't realize how much space a string takes up.
| On my machine replicate 500 'a' will use 90MB of space!
|
| You have to take into account that Chars (in GHC)
Am Freitag, 28. November 2003 12:10 schrieb Koen Claessen:
Wolfgang Jeltsch wrote:
| 1. Today I spend a few hours trying to track down a memory leak. It
| turns out I just didn't realize how much space a string takes up.
| On my machine replicate 500 'a' will use 90MB of
On Fri, Nov 28, 2003 at 11:31:51AM +0100, Wolfgang Jeltsch wrote:
On my machine replicate 500 'a' will use 90MB of space!
You have to take into account that Chars (in GHC) take 4 bytes of memory
because they denote Unicode codepoints. 5,000,000 times 4 bytes is already 20
MB. (The
On Fri, Nov 28, 2003 at 12:37:30PM +0100, Wolfgang Jeltsch wrote:
So, what is happening that there is 1 cell in the heap
containing the representation of 'a', and then a linked list
of length 500, where each element points to that cell.
Yes, you're right. But if you choose the array
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?
For me, there would rather be celebration :),
Am Freitag, 28. November 2003 19:21 schrieb Hal Daume III:
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
For me, there would rather be celebration :), especially if these could be
tuned to only use 8 bits.
What do you mean with this? Hopefully, not dropping Unicode support because
this would be a very bad idea, IMHO.
I mean to have the option of using Unicode or plain 8bit ascii as you see
Wolfgang Jeltsch wrote:
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?
For me, there
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. Hbc has had those implemented for maybe 10 years.
-- Lennart
On Fri, Nov 28, 2003 at 09:21:50PM +, Glynn Clements 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
(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 appropriate functions to convert to and from [Char]?
ajb:
G'day all.
Quoting Ben Escoto [EMAIL PROTECTED]:
Hi, can someone tell me why Haskell strings are linked lists?
Because that's the way it was done in Miranda, almost 20 years ago.
OK, to be fair, it does make string-to-string operations a bit more
convenient. Apart from
Ben writes:
Hi, can someone tell me why Haskell strings are linked lists? I have
had some problems with Haskell strings:
You may want to try Data.PackedString which comes with GHC (if you are
using GHC that is).
Cheers,
Bernie.
___
Haskell mailing
50 matches
Mail list logo
