> Wouldn't it be good to implement an LVM import/export feature in GHC, Hugs
> and nhc98?
To read and write lvm bytecodes?
That could be quite a lot of work because the bytecodes are specific to the
abstract machine and the abstract machines are different. Unless the LVM is
essentially just a
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
nhc9
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* do
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* don't know why?
Jerzy Karczmarc
hi,
In relation to my other message, I can contribute to this question. I
think it is very important and useful to consider Strings as Sequences of
Characters. And independently of the issue discussed elsewhere -- whether
Characters should be a type or a class -- I am asking whether Sequences
sh
Derek Elkins <[EMAIL PROTECTED]> writes:
> > What Haskell byte code projects are out there?
>
> 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.
Regards,
Malcolm
_
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.
>
> Y
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 chapt
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
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:
http://www.c
> > 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 g
> 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
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
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 ther
> 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 closur
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
> 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 grow
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 Stat
> 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
> 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 o
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 cl
> > 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
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 i
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 actual
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
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
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 conte
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
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 System.Posi
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
> 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 car
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 grea
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
> >
[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 prop
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
>
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
>
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
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 l
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
__
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 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 yo
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
> > riotin
> 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 :), es
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
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
> M
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 90
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 GH
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
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 h
On Thu, Nov 27, 2003 at 10:54:11PM -0500, [EMAIL PROTECTED] wrote:
> OK, to be fair, it does make string-to-string operations a bit more
> convenient. Apart from undergraduate homework exercises and some
> specific domains, though, this isn't exactly the "common case" of
> all situations where peo
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
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
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 undergraduate homewo
Hi, can someone tell me why Haskell strings are linked lists? I have
had some problems with Haskell strings:
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 u
54 matches
Mail list logo
