On Sat, May 10, 2008 at 7:20 AM, Neil Mitchell [EMAIL PROTECTED] wrote:
Jurriaan Hage and Stefan Holdermans. Heap recycling for lazy
languages. In John Hatcliff, Robert Glück, and Oege de Moor, editors,
_Proceedings of the 2008 ACM SIGPLAN Symposium on Partial Evaluation
and
Advanced technology ought to look like unpredictable magic.
My experience with lazy evaluation is such that every time a program is
slower or bulkier than I presumed, it is not arbitrariness, it is
something new to learn.
My experience with GHC is such that every surprise it gives me is a
On Mon, May 12, 2008 at 08:01:53PM +0100, Andrew Coppin wrote:
I offer up the following example:
mean xs = sum xs / length xs
Now try, say, mean [1.. 1e9], and watch GHC eat several GB of RAM. (!!)
I don't see why the performance implications of this program are surprising.
Just ask any
On Mon, May 12, 2008 at 4:38 AM, Richard Kelsall
[EMAIL PROTECTED] wrote:
Hello JC, I think you've set yourself a challenge there :) Welcome to
Haskell programming. Taking a Shootout entry and playing with it is
a great way to learn Haskell. The Shootout provides an example in your
Yes, I had always desired that the operator = should have been right
associative for this short cut even when written without the 'do' notation.
On Tue, May 13, 2008 at 3:39 AM, John Hamilton [EMAIL PROTECTED] wrote:
I'm trying to understand how short circuiting works with the Maybe monad.
Just a heads up - i only have a month or so experience with Haskell, so
alot of these issues may be my own fault.
Anyway, the log file that i'm parsing uses English grammar, and the
performance really dropped just by upgrading to Parsec3. I was hoping to
use the ByteString support to boost
gale:
Andrew Coppin wrote:
I offer up the following example:
mean xs = sum xs / length xs
Now try, say, mean [1.. 1e9], and watch GHC eat several GB of RAM. (!!)
If we now rearrange this to
mean = (\(s,n) - s / n) . foldr (\x (s,n) - let s' = s+x; n' = n+1 in s'
`seq`
Hi Andrew,
my probably dodgy reason for mentioning deforestation is that sharing
of intermediate values is a major stumbling block; code that uses data
linearly is possibly well suited for deforesting. See Frankau's SASL
for a language that deforests all lists simply by not letting you copy
I don't know why, but perhaps beginners may expect too much from the
laziness, almost to the level of magic (me too, in the beginning!). In an
eager language, a function like
mean :: (Fractional a) = [a] - a
expects the *whole* list before it can calculate the mean, and the question
of the
On 2008 May 13, at 0:26, J C wrote:
On the other hand, if the experts can't help using malloc, unsafe*,
global mutables and IO, I'll be able to conclude that this is probably
what it takes to make Haskell run fast :-(
Very few of the shootout entries have been revisited since most of the
On 2008 May 12, at 22:18, Jeff Polakow wrote:
Then, I immediately blow my stack if I try something like:
mean [1..10].
The culprit is actually sum which is defined in the base libraries
as either a foldl or a direct recursion depending on a compiler
flag. In either case, the
J C wrote:
[EMAIL PROTECTED] wrote:
Hello JC, I think you've set yourself a challenge there :) Welcome to
Haskell programming. Taking a Shootout entry and playing with it is
a great way to learn Haskell. The Shootout provides an example in your
favourite previous language for comparison
Well, it would be meaningful for your own experience in learning Haskell.
Some time ago somebody took a shot at nbodies using pure immutable
structures, and as I recall, got within about 4x the performance of mutable
structures. In 6.6, an STArray based approach was maybe 2x slower, but by
now it
On Tue, May 13, 2008 at 2:20 AM, Don Stewart [EMAIL PROTECTED] wrote:
Note the use of strict pairs. Key to ensuring the accumulators end up in
registers.The performance difference here is due to fold (and all left
folds) not fusing in normal build/foldr fusion.
The vector version
Bulat Ziganshin wrote:
Hello Richard,
Tuesday, May 13, 2008, 6:10:54 PM, you wrote:
because I was compiling my splitAt with -O2 optimisation as opposed
to the built-in version being compiled with -O. The extra optimisations
in -O2 are a new feature of GHC (and -O2 is slower to compile which
Hello Richard,
Tuesday, May 13, 2008, 7:56:36 PM, you wrote:
In July 2007 -O2 was documented in GHC as making no difference to
the speed of programs :
http://www.haskell.org/pipermail/haskell-cafe/2007-July/029118.html
it's because ghc is 15 years old and its documentation may be not
Darrin Thompson [EMAIL PROTECTED] wrote:
On Tue, May 13, 2008 at 2:20 AM, Don Stewart [EMAIL PROTECTED] wrote:
Note the use of strict pairs. Key to ensuring the accumulators
end up in registers.The performance difference here is due to
fold (and all left folds) not fusing in normal
Bulat Ziganshin wrote:
Hello Richard,
In July 2007 -O2 was documented in GHC as making no difference to
the speed of programs :
http://www.haskell.org/pipermail/haskell-cafe/2007-July/029118.html
it's because ghc is 15 years old and its documentation may be not
updated as things changes
Hello,
I would like to use a lazy, purely functional language to create an
experiement description (and execution!) language for cellular
neuroscience, i.e. electrical recordings and stimulation.
Unfortunately, this means I have to talk to a
Analog-to-Digital/Digital-to-Analog converter board,
Hi.
I am testing a winged edge data structure.
module Main where
type Point3 = (Float, Float, Float)
data Body= Body [Vertex] [Edge] [Face] deriving(Eq)
data Face= Face Edge deriving(Eq)
data Edge= Edge (Vertex, Vertex)
(Face, Face)
(Edge, Edge)
(Edge, Edge) deriving(Eq)
{-# LANGUAGE ScopedTypeVariables #-}
Data.Dynamic gives a passable impression of adding support for
dynamically typed code and runtime typing to GHC, without changing
the basic statically typed, all types known at runtime nature of the
language.
Note that Data.Dynamic relies upon two things:
Hi all,
Is it possible to expand macros defined in includes into the .hsc file? I'm
trying to call functions from a library written in C. The library can be
used with or without Unicode chars, depending on #define instructions.
The library has macros for all the standard functions used to work
Hello Jules,
Tuesday, May 13, 2008, 9:39:12 PM, you wrote:
This is close, and works as far as it goes. It is a limited
reimplementation of Dynamic which uses show/read instead of
there are gread/gshow funcs. don't know how these works, though :)
--
Best regards,
Bulat
Hello Eric,
Tuesday, May 13, 2008, 10:16:48 PM, you wrote:
-fallow-overlapping-instances doesn't convince GHC. Is there a way
around this other than manually writing out all the instances I want?
afaik, no. typeclasses are not the same as OOP classes. i suggest you
to look into
tanielsen:
Hello,
I would like to use a lazy, purely functional language to create an
experiement description (and execution!) language for cellular
neuroscience, i.e. electrical recordings and stimulation.
Unfortunately, this means I have to talk to a
Analog-to-Digital/Digital-to-Analog
On 2008-05-12, Andrew Coppin [EMAIL PROTECTED] wrote:
(Stupid little-endian nonsense... mutter mutter...)
I used to be a big-endian advocate, on the principle that it doesn't
really matter, and it was standard network byte order. Now I'm
convinced that little endian is the way to go, as bit
Aaron Denney [EMAIL PROTECTED] writes:
I used to be a big-endian advocate, on the principle that it doesn't
really matter, and it was standard network byte order. Now I'm
convinced that little endian is the way to go
I guess it depends a lot on what you grew up with. The names
(little/big
Jeff Polakow wrote:
[...] This can be easily fixed by defining a suitable strict sum:
sum' = foldl' (+) 0
and now sum' has constant space. We could try to redefine mean using
sum':
mean1 xs = sum' xs / fromIntegral (length xs)
but this still gobbles up memory. The reason is that xs
Yes. I guess I have to wait for chapter 19, then?
Tom
On Tue, May 13, 2008 at 7:35 PM, Don Stewart [EMAIL PROTECTED] wrote:
tanielsen:
Hello,
I would like to use a lazy, purely functional language to create an
experiement description (and execution!) language for cellular
Hi
Anyway, the log file that i'm parsing uses English grammar, and the
performance really dropped just by upgrading to Parsec3. I was hoping to use
the ByteString support to boost the speed of already slow code, but had no
such luck. It basicly went from Ugh, this is kinda slow to U i'm
On Tue, May 13, 2008 at 7:39 PM, Jules Bean [EMAIL PROTECTED] wrote:
One thing which you can't obviously do is write Read or Show instances
for Dynamic. So can we pass Dynamic data over the wire? If not,
Dynamic is limited to the context of within a single program, and
can't be used over
Neil Mitchell [EMAIL PROTECTED] writes:
I think it is known that Parsec 3 is slower than Parsec 2, as a result
of the increased generality. I know that in the past someone was
working on it, but I am not sure if they ever got anywhere.
I got pretty good performance (IMHO - about 10MB/s, still
On Tue 2008-05-13 20:46, Ketil Malde wrote:
Aaron Denney [EMAIL PROTECTED] writes:
I guess it depends a lot on what you grew up with. The names
(little/big endian) are incredibly apt.
The only argument I can come up with, is that big endian seems to make
more sense for 'od':
% echo
Jed Brown [EMAIL PROTECTED] writes:
This, of course, is because `od -x' regards the input as 16-bit integers. We
can get saner output if we regard it is 8-bit integers.
Yes, of course. The point was that for big-endian, the word size
won't matter. Little-endian words will be reversed with
Darrin Thompson wrote:
These tricks going into Real World Haskell?
Some will, yes.
For example, the natural and naive way to write Andrew's mean function
doesn't involve tuples at all: simply tail recurse with two accumulator
parameters, and compute the mean at the end. GHC's strictness
Am Dienstag, 13. Mai 2008 21:28 schrieb Aaron Denney:
On 2008-05-13, Ketil Malde [EMAIL PROTECTED] wrote:
Jed Brown [EMAIL PROTECTED] writes:
This, of course, is because `od -x' regards the input as 16-bit
integers. We can get saner output if we regard it is 8-bit integers.
Yes, of
Hello,
For example, the natural and naive way to write Andrew's mean function
doesn't involve tuples at all: simply tail recurse with two accumulator
parameters, and compute the mean at the end. GHC's strictness analyser
does the right thing with this, so there's no need for seq, $!, or the
Jed Brown [EMAIL PROTECTED] wrote:
It's not that simple with bits. They lack consistency just like the
usual US date format and the way Germans read numbers.
So you claim that you pronounce 14 tenty-four? In German pronunciation
is completely uniform from 13 to 99.
--
(c) this sig last
On Tuesday 13 May 2008, Jeff Polakow wrote:
Is this the code you mean?
meanNat = go 0 0 where
go s n [] = s / n
go s n (x:xs) = go (s+x) (n+1) xs
If so, bang patterns are still required bang patterns in ghc-6.8.2 to run
in constant memory:
meanNat = go 0 0 where
Don Stewart wrote:
Andrew, would you say you understand the original problem of why
mean xs = sum xs / fromIntegral (length xs)
was a bad idea now? Or why the left folds were a better solution?
That definition of mean is wrong because it traverses the list twice.
(Curiosity: would
Aaron Denney wrote:
On 2008-05-12, Andrew Coppin [EMAIL PROTECTED] wrote:
(Stupid little-endian nonsense... mutter mutter...)
I used to be a big-endian advocate, on the principle that it doesn't
really matter, and it was standard network byte order. Now I'm
convinced that little
Also, the way we write numbers is little endian when writing in
Arabic; we just forgot to reverse the digits when we borrowed the
notation.
Little endian is more logical unless you also number your bits with
MSB as bit 0.
On Tue, May 13, 2008 at 7:35 PM, Aaron Denney [EMAIL PROTECTED] wrote:
On
Hello,
I've tried to compile hsffig-1.0pl2, unsuccesfully, also from the
unstable darcs repo. I'm using ghc-6.8 (ghc6-6.8.2 from Debian
unstable). HSFFIG comes with its own version of Cabal, but I cannot get
past the configuration phase (./cabal-setup configure), when I get the
following output:
Paul: What is the underlying rationale for the Maybe data type?
It is the equivalent of a database field that can be NULL.
Paul: shock, horror! the null value or the absence of any
value denoted by null is not really in harmony with the relational model.
is it the
ndmitchell:
Hi
1. What is ghc-core?
You actually answer this question as part of question 2. Think of it
as simple Haskell with some additional bits.
2. Does anybody know how to actually read GHC's Core output anyway?
To me,
it looks almost exactly like very, very complicated
On Tue, 2008-05-13 at 19:48 +0100, Tom Nielsen wrote:
Yes. I guess I have to wait for chapter 19, then?
Just read the FFI Addendum:
http://www.cse.unsw.edu.au/~chak/haskell/ffi/
It's not complicated at all.
___
Haskell-Cafe mailing list
On 2008 May 13, at 17:01, Andrew Coppin wrote:
That definition of mean is wrong because it traverses the list
twice. (Curiosity: would traversing it twice in parallel work any
better?) As for the folds - I always *always* mix up
It might work better but you're still wasting a core that
On 2008 May 13, at 17:12, Andrew Coppin wrote:
[Oh GOD I hope I didn't just start a Holy War...]
Er, I'd say it's already well in progress. :/
--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED]
system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED]
I use a trick like this to allow saving of dynamics into ho files for
jhc, the same thing will work for network connections.
see Info.Info for the data type, and Info.Binary for the binary
serialization routines.
http://repetae.net/dw/darcsweb.cgi?r=jhc;a=tree;f=/Info
John
--
John
On 2008.05.13 23:31:17 +0200, Harri Kiiskinen [EMAIL PROTECTED] scribbled
1.1K characters:
Hello,
I've tried to compile hsffig-1.0pl2, unsuccesfully, also from the
unstable darcs repo. I'm using ghc-6.8 (ghc6-6.8.2 from Debian
unstable). HSFFIG comes with its own version of Cabal, but I
Andrew Coppin wrote:
2. Does anybody know how to actually read GHC's Core output anyway? To
me, it looks almost exactly like very, very complicated Haskell source
with a suspicious concentration of case expressions - but I understand
that in the Core language, many constructs actually mean
I have a few questions about commutative monads and applicative functors.
From what I have read about applicative functors, they are weaker than
monads because with a monad, I can use the results of a computation to
select between alternative future computations and their side effects,
whereas
Philippa Cowderoy wrote:
On Tue, May 13, 2008 5:53 am, Neal Alexander wrote:
I can post the full profiling info if anyone really cares.
Any info is helpful. It's taking a while to get round to things, but the
more relevant info we have to hand when we do the easier it is to improve
things
On Tue, May 13, 2008 at 9:23 PM, Neal Alexander [EMAIL PROTECTED] wrote:
I stripped the code down to just the parsec related stuff and retested it.
http://72.167.145.184:8000/parsec_test/Parsec2.prof
http://72.167.145.184:8000/parsec_test/Parsec3.prof
And the parser with a 9mb (800 kb
Hello Antoine,
Wednesday, May 14, 2008, 8:43:47 AM, you wrote:
Is this expected? I don't really understand why adding an extra layer
of indirection should speed things up.
adding laziness may improve performance by avoiding calculation of
unnecessary stuff or moving into into later stage
On 14 May 2008, at 8:58 am, Andrew Coppin wrote:
What I'm trying to say [and saying very badly] is that Haskell is an
almost terrifyingly subtle language.
Name me a useful programming language that isn't.
Simply interchanging two for-loops, from
for (i = 0; i N; i++) for (j = 0; j
Graham Fawcett wrote:
Yes, but that's still a 'quick' short-circuiting. In your example, if
'n' is Nothing, then the 'f = g = h' thunks will not be forced
(thanks to lazy evaluation), regardless of associativity. Tracing
verifies this:
No, it doesn't. What your tracing verifies is that the f,
57 matches
Mail list logo
