#684: Pending occurrence-analysis fix
-+--
Reporter: simonpj |Owner: simonpj
Type: bug | Status: new
Priority: normal|Milestone: 6.6
Component: Compiler |
I agree 100% with you. We absolutely do intend to support 6.4.2 as a
stable compiler for a long time yet. But this particular bug has been
in the compiler for years, and only reported once. I very much doubt
that anyone will even notice whether or not we fix 6.4.2.
Still, if any two people
Hi all,
What is the status of Rob Ennals' optimistic evaluation work? I'm told
that it has been removed from GHC. This is extremely depressing to me.
Without such a feature available, it becomes very difficult to write
programs that process large amounts of data in Haskell. In many such
On Tue, Feb 07, 2006 at 08:28:51PM +, Frederik Eaton wrote:
What is the status of Rob Ennals' optimistic evaluation work? I'm told
that it has been removed from GHC. This is extremely depressing to me.
Without such a feature available, it becomes very difficult to write
programs that
On Tue, Feb 07, 2006 at 09:52:49PM +0100, Tomasz Zielonka wrote:
There's also a related idea to decrease the priority of garbage
producing threads (and/or increase for garbage reducing threads). This
way it would be possible to make the idiomatic Haskell 'wc' (word count)
implementation space
Hello GHC,
Tuesday, February 07, 2006, 8:03:49 PM, you wrote:
G someone mentioned to me that this expression:
GmapM_ action [n..m]
G isn't being optimised properly, so I thought I'd look into it. Sure
may be, what's me :) i use specially written function as faster
version of this idiom
I need to pass a big 2-dimensional array of doubles from a legacy
C code to a Haskell module. Of this huge array, the Haskell code will
actually use only
a few elements (say, 10 out of 100x20 matrix). Unfortunately, the C code
does not know
which data are actually needed in the Haskell module.
Cyril Schmidt wrote:
I need to pass a big 2-dimensional array of doubles from a legacy
C code to a Haskell module. Of this huge array, the Haskell code will
actually use only
a few elements (say, 10 out of 100x20 matrix). Unfortunately, the C code
does not know
which data are actually needed
On Tue, Feb 07, 2006 at 09:52:49PM +0100, Tomasz Zielonka wrote:
... I was wondering if it would be possible ...
There's also a related idea ...
I've heard that the implementation of optimistic evaluation was rather
complex, which was the main reason not to include it in GHC (yet).
That's why
The ability to use functions 'catch', 'bracket', 'catchDyn', etc. in
MonadIO other than IO itself has been a fairly frequently requested
feature:
http://www.haskell.org/pipermail/glasgow-haskell-users/2003-September/005660.html
http://haskell.org/pipermail/libraries/2003-February/000774.html
[EMAIL PROTECTED] writes:
The implementation is quite trivial.
class MonadIO m = CaughtMonadIO m where
gcatch :: m a - (Exception - m a) - m a
instance CaughtMonadIO IO where
gcatch = Control.Exception.catch
instance (CaughtMonadIO m, Error e) = CaughtMonadIO (ErrorT e m)
Hello John,
Tuesday, February 07, 2006, 4:23:36 AM, you wrote:
data Eq a = Set a = Set (List a)
that is a sort of extension i will be glad to see. in my Streams
library, it's a typical beast and i forced to move all these contexts
to the instances/functions definitions:
data
On 2/5/06, Jim Apple [EMAIL PROTECTED] wrote:
Have we considered Restricted Data Types?
http://www.cs.chalmers.se/~rjmh/Papers/restricted-datatypes.ps
Nice to see my old paper hasn't sunk without trace!
As Taral pointed out, though, Restricted Data Types have not been implemented,
and
Am Freitag, 3. Februar 2006 00:06 schrieb John Meacham:
On Thu, Feb 02, 2006 at 03:09:35PM +, Henrik Nilsson wrote:
Now, I'm not saying that FDs are that important, only that it seems
to me they are. I'd be happy to be convinced of the opposite.
But from the above, it at least seems
From: Ross Paterson [EMAIL PROTECTED]
John Hughes wrote:
I would urge that either we stick with the present design, or, if bang
patterns are added (which a lot speaks for), that the language be
simplified at the same time so that patterns are matched in the same way
everywhere, and
From: John Meacham [EMAIL PROTECTED]
Subject: Re: Restricted Data Types
however, what prevents the following from being _infered_
return Foo :: Moand m = m Foo
so, we think we can specialize it to
return Foo :: Set Foo
however, we no longer have the constraint that Foo must be in Eq!
Maybe
John Hughes wrote:
That means that the Monad class is not allowed to declare
return :: a - m a
because there's no guarantee that the type m a would be well-formed. The
type declared for return has to become
return :: wft (m a) = a - m a
I'm confused. It seems like the type (a - m a)
On Jan 31, 2006, at 1:50 PM, Wolfgang Jeltsch wrote:
Am Montag, 30. Januar 2006 19:33 schrieb Isaac Jones:
[...]
Have you looked at the Helium language / compiler? It's a
stripped-down version of Haskell for teaching. Maybe that's what
you're actually suggesting? I think this is a great
On Tue, Feb 07, 2006 at 10:04:35AM +0100, Georg Martius wrote:
From the users point of view, the implementation in GHC works quite
well and a lot people use it. It would be a pity if they are not
included in the new standard. What is the problem of specifying what
is implemented.
They work
On Feb 7, 2006, at 9:49 AM, Malcolm Wallace wrote:
Robert Dockins [EMAIL PROTECTED] writes:
i would argue against treating tuples as pure syntactic sugar for
nested pairs; since the nesting carries hierarchical information, i
would expect (x,y,z) used in place of (x,(y,z)) to cause an error.
| Have we considered Restricted Data Types?
|
| http://www.cs.chalmers.se/~rjmh/Papers/restricted-datatypes.ps
|
|
| Finally, I wrote my paper before fundeps came on the scene. Some of
the contortions I went through
| in my simulation of RDTs could be avoided with the help of fundeps.
A key
| data Eq a = Set a = Set (List a)
|
| that is a sort of extension i will be glad to see. in my Streams
| library, it's a typical beast and i forced to move all these contexts
| to the instances/functions definitions:
Another reasonable alternative is
data Set a = Eq a = Set (List a)
Hello Robert,
Tuesday, February 07, 2006, 6:42:41 PM, you wrote:
More disturbing is the complete inability to write general functions
over tuples.
RD As I understand it, you still have to write down the instance
RD declarations when using '-fgenerics'.
only one generic instance. it's very
On Feb 7, 2006, at 11:29 AM, Bulat Ziganshin wrote:Hello Robert,Tuesday, February 07, 2006, 6:42:41 PM, you wrote: More disturbing is the complete inability to write general functionsover tuples. RD As I understand it, you still have to write down the instance RD declarations when using
Simon PJ thinks that Haskell' should include scoped type variables, and I
tend to agree. But I'm unhappy with one aspect of the way they're
implemented in GHC. What I don't like is that given a signature like
x :: a - a
there's no way to tell, looking at it in isolation, whether a is free
Bulat Ziganshin wrote:
{-# OPTIONS_GHC -fglasgow-exts #-}
main = do return xx = ((\x - print x) :: Show a = a - IO ())
main2 = do return xx = (\(x:: (forall a . (Show a) = a)) - print x)
main3 = do (x :: forall a . Show a = a) - return xx
print x
in this module, only main compiles ok
Simon Peyton-Jones wrote:
Another reasonable alternative is
data Set a = Eq a = Set (List a)
The type of member would become
member :: a - Set a - Bool
(with no Eq constraint).
John Hughes mentions this in section 5.2 of the paper, and points out a
problem: a function like
Ben Rudiak-Gould wrote:
Simon PJ thinks that Haskell' should include scoped type variables, and
I tend to agree. But I'm unhappy with one aspect of the way they're
implemented in GHC. What I don't like is that given a signature like
x :: a - a
there's no way to tell, looking at it in
From: Ben Rudiak-Gould [EMAIL PROTECTED]
Subject: Re: Bang patterns, ~ patterns, and lazy let
It's also not that case that !x has the same
meaning in both proposals, e.g.
let { !x = y ; !y = const 'a' x } in x
means 'a' in the current proposal but _|_ in yours.
Aargh,
John Meacham wrote:
however, (Set (a - a)) is malformed. since a _requirement_ is that Set
can only be applied to a type with an Eq constraint so the instance you
try to do something like
returnid :: Set (a - a) -- ^ static error! you need
returnid :: Eq (a - a) = Set (a - a)
the instant you
On Tue, Feb 07, 2006 at 07:59:46PM -0800, Ashley Yakeley wrote:
John Meacham wrote:
however, (Set (a - a)) is malformed. since a _requirement_ is that Set
can only be applied to a type with an Eq constraint so the instance you
try to do something like
returnid :: Set (a - a) -- ^ static
Hello Peter,
Tuesday, February 07, 2006, 4:05:55 AM, you wrote:
PS | Examples$ ghc -i.. -O2 -funbox-strict-fields --make wc.hs -o wc
btw, in my programs (and in this lib) i explicitly unbox all the
strict fields with simple types because automatic unboxing can lead
to losed sharing of
Graham Klyne [EMAIL PROTECTED] escribió en el mensaje
news:[EMAIL PROTECTED]
One of the features of Haskell that I like is that it doesn't require lots
of
IDE support to write complex programs... the compact syntax and clean
separation
of concerns that can be achieved make it iasy enough
Brian Hulley wrote:
One motivation seems to be that in the absence of whole program
optimization, the strictness annotations on a function's type can allow
the compiler to avoid creating thunks at the call site for cross-module
calls whereas using seq in the function body itself means that the
On the new wiki, there is a keyword page as well (probably copied from
the old wiki):
http://haskell.org/haskellwiki/Keywords
I agree that it would be nice to have a reference card page much
like yours, Neil. So I made it on the wiki:
http://www.haskell.org/haskellwiki/Reference_card
By the way,
Ben Rudiak-Gould wrote:
Brian Hulley wrote:
One motivation seems to be that in the absence of whole program
optimization, the strictness annotations on a function's type can
allow the compiler to avoid creating thunks at the call site for
cross-module calls whereas using seq in the function
I just wanted to say thanks for posting that, I have been struggling
with a similar problem and I still haven't fully wrapped my head around
Typeable and fundeps so that PList code you posted helped immensely.
Cheers,
Scott
On 05/02/2006, at 3:57 AM, J. Garrett Morris wrote:
On 2/4/06,
Simon Marlow wrote:
I suggest you follow the same scheme as the unboxed array types, and
have IOURef/STURef types, parameterised over the element type. Of
course, we should have instances for all of the primitive numeric types
plus Ptr, ForeignPtr, StablePtr, Bool.
Perhaps it may be worth
The trouble with monad comprehensions was that it became far too easy to
write ambiguous programs, even when you thought you were just working with
lists.
One solution was already suggested: to make the comprehension syntax be pure
syntactic sugar whose semantics depends on the semantics of
Hello oleg,
Wednesday, February 08, 2006, 8:37:55 AM, you wrote:
I suggest you follow the same scheme as the unboxed array types, and
have IOURef/STURef types, parameterised over the element type. Of
course, we should have instances for all of the primitive numeric types
plus Ptr,
40 matches
Mail list logo
