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
Bugs item #847910, was opened at 2003-11-24 00:57
Message generated for change (Comment added) made by simonmar
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=108032aid=847910group_id=8032
Category: None
Group: 6.0.1
Status: Closed
Resolution: Fixed
Priority: 5
Bugs item #831333, was opened at 2003-10-28 08:23
Message generated for change (Comment added) made by dons
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=108032aid=831333group_id=8032
Category: Runtime System
Group: None
Status: Open
Resolution: None
Priority: 5
HI:
Reading Haskell 98 FFI report, one question arised:
Imported and declared a foreign function , via
foreign import ccall foo:: IO(CInt)
Is it guaranteed to be executed in atomic way ? I mean , should it
block the whole STG system ?
Idea: To implement a monitor , in a external context , and
(follow-ups to the FFI list please)
Rafael Martinez Torres wrote:
HI:
Reading Haskell 98 FFI report, one question arised:
Imported and declared a foreign function , via
foreign import ccall foo:: IO(CInt)
Is it guaranteed to be executed in atomic way ? I mean , should it
block the whole STG
Well, similar ideas have been brought up before, and I'm a bit
sceptical:
*) Why should we introduce a feature at the language level for solving
a problem that is already solved by MVars? You can write your own
combinators to reduce the hassle of using MVars to a minimum.
Firstly, thanks
At 21:03 27/11/03 -0500, Derek Elkins wrote:
On Thu, 27 Nov 2003 14:56:03 +
Graham Klyne [EMAIL PROTECTED] wrote:
(perhaps a more serious and to the point reply later)
But not all cases I encounter involve lists or monads. A different
case might look like this:
Are you sure this doesn't
(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]?
19 matches
Mail list logo
