#663: Confusion about types
--+-
Reporter: guest| Owner:
Type: bug | Status: closed
Priority: normal | Milestone:
#655: Loading the GHC library from GHCi.
---+
Reporter: Lemmih| Owner:
Type: feature request | Status: new
Priority: normal| Milestone: 6.6
Hello John,
Thursday, January 19, 2006, 4:42:47 AM, you wrote:
sorry, with the gcc -O3 -ffast-math -fstrict-aliasing -funroll-loops
the C version is 50 times faster than best Haskell one... it's the
loop from C version:
JM I believe something similar to what I noted here is the culprit:
JM
John Meacham wrote:
On Wed, Jan 18, 2006 at 06:18:29PM +0300, Bulat Ziganshin wrote:
:) even C version performs only 20 millions of additions in one second
because this program is most limited by memory throughput - it access
to 24 memory bytes per each addition. GHC just can't produce simple
John Meacham wrote:
On Wed, Jan 18, 2006 at 08:54:43PM +0300, Bulat Ziganshin wrote:
sorry, with the gcc -O3 -ffast-math -fstrict-aliasing -funroll-loops
the C version is 50 times faster than best Haskell one... it's the
loop from C version:
I believe something similar to what I noted here is
Thanks Lemmih. I already fixed this error. The module declaration in my Main file was giving it a wrong name (not Main).Thank you. Lemmih [EMAIL PROTECTED] escreveu: On 1/18/06, Tays Soares wrote: I'm trying to run the following sequence on ghc 6.4: ghc -fglasgow-exts --make Main ghc -o
I tweaked the IORegions code using some other ideas from the thread.
The IOM marks a monad which wrapped (IO a) is now IOQ marks m a
which wraps m a. So it is a MonadTrans and if m is MonadIO then so is
IOQ marks m.
qGetChar was just a demo, and has been replaced by liftH, liftH2, and
liftH3
Simon Peyton-Jones wrote:
Previously I've thought of using a nested tuple type
(m1, (m2, (m3 (
That was my thought too. But then we need the comparison operation on
those 'm' (which are actually type eigen-variables). Not that it can't
be done (it can, and several examples prove
Hi all
In object-oriented programming, UML is used to model programs. In
functional programming (especially Haskell) we use ???
The only graphical modellering language I have found is FAD:
http://www.cs.kent.ac.uk/pubs/2001/1152/ .
Are there other approaches?
Are anybody, except for the
On Thu, 19 Jan 2006, Mads [ISO-8859-1] Lindstrøm wrote:
Hi all
In object-oriented programming, UML is used to model programs. In
functional programming (especially Haskell) we use ???
Haskell :-)
I am mainly interested in the macro level. That is modules, classes,
class instances, ...
Dominic Steinitz wrote:
Can someone give an explanation of how the marks get built up?
Suppose we have a class TypeEq a b so that the constraint TypeEq holds
whenever a and b are the same. Then the type Int and the type
TypeEq a Int = a
are kind of equivalent, right? The HList library
Mads Lindstrøm wrote:
In object-oriented programming, UML is used to model programs. In
functional programming (especially Haskell) we use ???
Nice question.
The problem with UML class diagrams is that they are
only really suited to classical OO (composition and inheritance)
and thus are
Philippa Cowderoy and Mads Lindstrom wrote:
- Original Message -
From: Philippa Cowderoy [EMAIL PROTECTED]
To: Mads Lindstrøm [EMAIL PROTECTED]
Cc: haskell@haskell.org
Sent: Thursday, January 19, 2006 8:16 AM
Subject: Re: [Haskell] Modelling languages for FP (like UML for OO)
On Thu,
On Thursday 19 January 2006 14:09, Mads Lindstrøm wrote:
In object-oriented programming, UML is used to model programs. In
functional programming (especially Haskell) we use ???
However, not everyone in the OO camp thinks that UML is really useful:
Two new papers available:
Book review
The Haskell Road to Logic, Maths and Programming by Kees Doets and Jan van
Eijck
To appear in JoLLI journal; 13 pages.
http://www.cs.vu.nl/~ralf/JoLLI06
Executive summary: The Haskell road is an excellent book worth
considering as course material and reading
Sean Seefried wrote:
Dominic Steinitz wrote:
Can someone give an explanation of how the marks get built up?
Suppose we have a class TypeEq a b so that the constraint TypeEq holds
whenever a and b are the same. Then the type Int and the type
TypeEq a Int = a
are kind of equivalent,
On Thu, Jan 19, 2006 at 09:09:36AM -0800, Ralf Lammel wrote:
Google's MapReduce Programming Model -- Revisited
Draft; To be submitted; feedback appreciated; 27 pages.
http://www.cs.vu.nl/~ralf/MapReduce
Executive summary: The seminal MapReduce paper had been briefly
discussed at LTU without
G'day all.
Quoting Benjamin Franksen [EMAIL PROTECTED]:
However, not everyone in the OO camp thinks that UML is really useful:
http://archive.eiffel.com/doc/manuals/technology/bmarticles/uml/page.html
Having actually used it (once), the consensus seems to be:
1. It only applies to a pure OO
Hello Chad,
Thursday, January 19, 2006, 1:09:38 AM, you wrote:
SC parameter. The input file is over 1 million lines long. Any ideas?
see at the BlockIO and FastIO libraries
http://cryp.to/blockio/blockio-2004-10-10.tar.gz
http://www.isi.edu/~hdaume/haskell/FastIO.tar.gz
--
Best regards,
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Andrew Pimlott wrote:
liftR :: (InRegion mark marks) = (h - m a) - Private mark h - Region marks
m a
liftR f (Private h) = Region $ f h
This is not as safe. Try modifying your test2.
Okay, I missed this... Have renamed the function unsafeLiftR... As you
say still useful for
Thanks, Bulat. Taking a look at Hal's FastIO library now...
Hal, it looks like your library could be helpful, especially if there is
a way to construct a FastIO.Handle from stdin. Can this be done, or do I
need to start with an actual file?
Thanks,
Chad
Brandon Moore [EMAIL PROTECTED] writes:
(snip)
The term I've heard is skolem constant, which is a freshly invented
thing distinct from everything else.
(snip)
There's a nice easy-going example in chapter 8 of
http://www.cl.cam.ac.uk/Teaching/2000/LogicProof/notes.pdf
where quantifiers are
On Thu, 2006-01-19 at 19:18 -0800, [EMAIL PROTECTED] wrote:
. . .
_variables_. The paper argues, btw, for the separation of those senses
and for a new quantifier to mean uniqueness only. In short, when we
write
forall x. forall y. body
then x may well be equal to y (in body). And
Bill Wood wrote:
is |nabla x, nabla y. phi(x,y)| logically equivalent to
|forall x, forall y. x y only-if phi(x,y)|? I use |P only-if Q| for
|P materially implies Q|
First of all, I should remark that Miller and Tiu introduce two
calculi (with names that are hardly speakable, even in TeX).
25 matches
Mail list logo
