On Wed, Aug 31, 2011 at 4:21 PM, Simon Peyton-Jones
simo...@microsoft.com wrote:
There seems to be a lot of support for Option 3... but what about Option 2
(ie pre-empt but give a warning)?
I notice that the idea to only issue a warning if the explicit and
implicit instances are in different
On Mon, Aug 29, 2011 at 6:21 AM, Bas van Dijk v.dijk@gmail.com wrote:
Won't option 1 Reject this as a duplicate instance declaration, which
indeed it is. conflict with design goal 1: a class C can be
re-factored into a class C with a superclass S, without disturbing any
clients?
If yes,
This is interesting.
I think using a slightly different notation would avoid confusion with
matching on tuples. Why not just write
docase a,b,c of
instead of
docase (a,b,c) of
?
Sebastian
On Thu, Aug 25, 2011 at 9:48 PM, Tomas Petricek
tomas.petri...@gmail.com wrote:
Hello,!
at
2011/3/25 Thomas Schilling nomin...@googlemail.com:
unsafePerformIO traverses the stack to perform blackholing. It could
be that your code uses a deep stack and unsafePerformIO is repeatedly
traversing it. Just a guess, though.
Sounds reasonable. Here is a variant of the program without
On Mon, Feb 14, 2011 at 1:41 PM, John Meacham j...@repetae.net wrote:
Isn't this what data families (as opposed to type families) do?
On Tue, Feb 15, 2011 at 7:02 AM, Conal Elliott co...@conal.net wrote:
Yes, it's one things that data families do. Another is introducing *new*
data types
Hello,
I want to use the RULES pragma and cannot get my rules to fire. Here is a
simplified example of what I'm trying.
I define my own version of foldMap for lists:
fold :: Monoid m = (a - m) - [a] - m
fold f = foldr mappend mempty . map f
-- alternative, trying to avoid
Why don't the rules fire,
Because the 'match' is at the wrong type.
This was the correct hint, thanks!
what can I change such that they do,
Type signatures.
Initially, I thought that just leaving out the polymorphic signature should
fix the problem. But I think it cannot be fixed by
On Nov 6, 2010, at 8:22 AM, David Peixotto wrote:
To summarize, I found that it is possible to get LLVM to do this
transformation through a combination of tail-call elimination,
inlining,
induction variable optimization, and global value numbering.
Interesting. This approach requires `f`
Which proposal do you mean?
I referred to Christian's questions whether it is possible to generate
`ff` and `gg` from `f` and `g`. If `h` is similar to `g`, then `hh`
could reuse `ff` while with an inlining approach something like `ff`
would be duplicated.
I'm not sure something like
On Oct 22, 2010, at 5:20 PM, Simon Peyton-Jones wrote:
I vote for this. In fact I've created a ticket for it.
http://hackage.haskell.org/trac/ghc/ticket/4426
+1 (I decided to prefer simplicity over convenience in this case)
Sebastian
___
Hi Simon,
thank you for your explanations. Now I understand why type variables
are quantified at the outermost position in function types.
My confusion was caused by implicit quantifications in data type
declarations. These are not (explicitly) mentioned in the
documentation that you
On Oct 21, 2010, at 9:58 PM, Simon Peyton-Jones wrote:
A implicit quantification point is
a) the type in a type signature f :: type, or
b) a type of form (context = type), that is not
enclosed by an explicit 'forall'
not quite:
foo :: forall a . a - (Ord b = b) - ()
On Oct 21, 2010, at 9:58 PM, Simon Peyton-Jones wrote:
So GHC's behaviour is probably about right, but the description is
wrong.
On Oct 21, 2010, at 11:14 PM, Sebastian Fischer wrote:
An implicit quantification point is
a) the type in a type signature f :: type or
b) a type
Hello,
GHC 6.12.3 allows to omit the explicit quantification of
higher-rank type variables using 'forall' in data types if they
appear in a type class context
{-# LANGUAGE RankNTypes #-}
data Foo = Foo (Eq a = a)
Is this implicit introduction of 'forall' intended? If it is, why
does it
Dear GHC experts,
say I have
module A where
class C a where ...
f :: C a = String - a
module B where
import A
data T = ...
instance C T where ...
g :: String - SomeOtherType
g s = doSomethingWith (f s)
Is it possible to SPECIALIZE `f` for the type `T`?
If
On Jul 28, 2010, at 5:40 PM, Max Bolingbroke wrote:
SPECIALISE pragmas are not supported in any but the defining module
because the Core for a function to specialise is not guaranteed to be
available in any other module.
Would it be reasonable (and possible) to reject specialization only if
Is the above output intended?
Yes.
Interesting.
Note that catching all exceptions is rarely the right thing to do. See
http://www.haskell.org/ghc/docs/6.12.2/html/libraries/base-4.2.0.1/Control-Exception.html#4
for more details.
I should have written
go_ahead :: NonTermination -
Hello,
GHC can spot (some) non-terminating computations and terminate with
blackhole: loop
instead of running indefinitely. With exception handling one can
handle such situations. The following program 'launches missiles':
import Control.Exception
main = do handle go_ahead
Dear GHC experts,
Certain behaviour when using
{-# LANGUAGE GADTs, TypeFamilies #-}
surprises me. The following is accepted by GHC 6.12.1:
data GADT a where
BoolGADT :: GADT Bool
foo :: GADT a - a - Int
foo BoolGADT True = 42
But the following is not:
data family
Is this perhaps another instance of #3851?
http://hackage.haskell.org/trac/ghc/ticket/3851
Honestly: I don't know.
My example is different from the one shown in #3851 in that it also
does not work in GHC 6.10 (which even panics instead of giving the
error 6.12 gives) and in that it uses a
but later in the comments I show an example with data families
which fails on both 6.10.4 and 6.12.1.
Ah, I think I misinterpreted your comment, when I read it for the
first time. Thanks for pointing me at it again. But I still don't see
whether or not the two examples are related. At
With GADTs, the specific choice of constructor is what gives you the
type matching functionality.
My intention was to use a GADT as data family instance (hence, I wrote
it in GADT style and it was accepted as such). Can't GADTs be used as
data family instances?
Sebastian
--
On Apr 15, 2010, at 3:44 PM, Sittampalam, Ganesh wrote:
You were trying to choose between different top-level types (which
happen to be instances of the same family) by their constructors.
That is true. I was trying to emulate an open data type such that I
can write
-- does not work
On Feb 4, 2010, at 8:58 AM, Simon Peyton-Jones wrote:
Unless I have a sudden revelation I don't expect to implement
pattern splices anytime soon.
On the other hand, pattern *quasiquotes* are fine; they are run by
the renamer before scope analysis is done. So you can certainly say
On Feb 3, 2010, at 1:48 AM, Max Bolingbroke wrote:
2010/2/2 Twan van Laarhoven twa...@gmail.com:
class Quoted a where
parseQuote :: String - a
-- for performance reasons:
parseQuote' :: Ghc.PackedString - a
Great idea!
Thinking about it, you can use type classes to
On Feb 3, 2010, at 6:13 PM, Max Bolingbroke wrote:
With a class-based approach only one parser that creates values of
the same
type could be used in a program.
This is not the case, because you still have an instance Quoted
String. Then you can write:
$(myLang [|..|])
Where myLang ::
Dear Simon,
I want to generate data type declarations using quasi quotes and hence
support the proposal to allow quasi quotation at declaration level.
With respect to syntax, I'd prefer [|blah| ... |] over the current
[$blah| ... |] and would also be fine with [blah| ... |].
What is the
On Feb 1, 2010, at 11:46 PM, Jason Dusek wrote:
Wouldn't `(|' and `|)' be safer?
I like this suggestion. It avoids conflicts with Template Haskell and
list comprehensions. Conor McBride also picked these brackets as idiom
brackets in his preprocessor she.
[$blah| ... |] could be
On Jun 2, 2009, at 1:57 PM, Simon Marlow wrote:
We'd probably need to find a suitably minimal Linux install, or
start from an existing minimal Linux VM image.
There is a german article [1] how to combine BusyBox [2] with a linux
kernel to get a full (restricted, but small) linux system.
On Jun 4, 2009, at 10:05 AM, Simon Peyton-Jones wrote:
What would really help is a self-contained program that demonstrates
the problem. Maybe that's what you've supplied. I'm confused
though. You say
If I remove any of them (one is enough) then
the program finishes in
On Jun 4, 2009, at 11:42 AM, Simon Marlow wrote:
Those two [1..] ring alarm bells. GHC will happily combine them
with CSE and possibly also lift them to the top-level; both
transformations might have a big impact on space behaviour.
Try with -fno-full-laziness and/or -fno-cse.
I did
On Jun 4, 2009, at 2:33 PM, Sebastian Fischer wrote:
Try with -fno-full-laziness and/or -fno-cse.
I did and found no difference when using any or both of these flags.
As int-e pointed out on the ticket that was my fault (spuriously
abstracting from command-line argument order). -fno-full
Hello,
I have written a Haskell program that runs much more efficiently
without optimisations than with optimisations.
Compiled without optimisations it finishes in about 15 seconds and
runs in constant space ( 3 MB), with optimisations (both -O and -O2)
it consumed all my RAM in less
Thanks for pointing me at Iavors package. We should not have two
different libraries for the same purpose.
value-supply-0.2 is about 6-7 times slower than GHC's UniqSupply, but
porting Simons suggestion (to use unsafeDupableInterleaveIO) into
Iavors code, GHC is only about twice as fast.
On Dec 17, 2008, at 10:54 AM, Sebastian Fischer wrote:
Would it be possible to put everything concerned with unique
identifiers in GHC into a separate package on Hackage?
I have wrapped up (a tiny subset of) GHC's uniques into the package
`uniqueid` and put it on Hackage:
http
Hello,
for a project I am using the libraries Unique, UniqSupply, and UniqFM
from the package ghc. It seems odd to have a dependency on a whole
compiler only in order to use its (highly efficient and, hence,
preferred) implementation of unique identifiers.
Would it be possible to put
36 matches
Mail list logo
