To me, perhaps naively, IncoherentInstances is way more scary than
OverlappingInstances.
What behavior do these new pragmas have? In particular, will it be an error if
there is no single most specific instance? And can the user decide whether it is
an error?
Twan
On 29/07/14 11:11, Simon
On 02/07/13 10:57, Simon Peyton-Jones wrote:
Here is Plan A: use fundep (or type function)
class Has r f t | r f - t where
getFld :: r - t
instance Has (R a) “foo” (a - a) where ..
instance Has S “bar” (forall b. b - b) where ...
Lacking (as we still do) impredicative
On 2012-07-12 23:48, Bulat Ziganshin wrote:
another interesting feature may be ruby-style matching defined by
execution of special function `match` instead of pattern matching:
switch var of
1+1 - print var==2
[5..10] - print var in [5..10]
(20) - print var20
where (var `match`
On 09/07/12 14:44, Simon Marlow wrote:
I now think '\' is too quiet to introduce a new layout context. The pressing
need is really for a combination of '\' and 'case', that is single-argument so
that we don't have to write parentheses. I think '\case' does the job
perfectly. If you want a
On 05/07/12 17:22, wagne...@seas.upenn.edu wrote:
Well, for what it's worth, my vote goes for a multi-argument \case. I find the
comment on the wiki page about mistyping \case Just x instead of \case (Just
x) a lot a bit disingenuous, since you already need these parens with today's
lambda.
On 2012-07-05 23:04, Edward Kmett wrote:
A similar generalization can be applied to the expression between case and of
to permit a , separated list of expressions so this becomes applicable to the
usual case construct. A naked unparenthesized , is illegal there currently as
well. That would
On 2012-03-09 02:13, Johan Tibell wrote:
Hi,
I just ran across some code that calls unsafeThawArray#, writeArray#,
and unsafeFreezeArray#, in that order. How unsafe is that?
Quick follow up question:
Are unsafeThawArray# and unsafeFreezeArray# guaranteed to not make a copy? I.e.
are these
On 03/03/12 01:40, Johan Tibell wrote:
Hi all,
These ideas are still in very early stages. I present them here in hope
of starting a discussion. (We discussed this quite a bit at last year's
ICFP, I hope this slightly different take on the problem might lead to
new ideas.)
I think the next big
On 25/01/12 16:21, Thijs Alkemade wrote:
Hello!
...
Examples:
*Main :t [__, ()]
tcRnExpr2: [(interactive:1:2-3, ())]
[__, ()] :: [()]
*Main :t map __ __
tcRnExpr2: [(interactive:1:5-6, a0 - b), (interactive:1:8-9, [a0])]
map __ __ :: [b]
You can do something similar right now with
On 06/12/11 18:48, wren ng thornton wrote:
So, I have an optimization/internals question. Does the GHC API have any
hooks for being able to revert a CAF to the original expression, thus
discarding the previously computed result?
...
I could hack something together based on unsafePerformIO and
Max Bolingbroke wrote:
2010/2/2 Isaac Dupree m...@isaac.cedarswampstudios.org:
I'm concerned in both your proposals, that single-letter names like t and
d are common function parameters, thus possibly producing
- shadowing warnings for all such functions in modules that happen to use TH
-
Hello Ghc people,
I have been working on adding support for derive Functor to ghc. I have a
patch that mostly works, but there are some problems:
1. Ghc reports the correct instance when I use -ddump-deriv:, but that instance
is not subsequenctly used. Instead I get a warning like:
I am having some problems with the latest builds of GHC on windows. For some
reason ghc has decided to use backslashes in filenames. This leads to
problems when building the stage libraries and the stage 2 compiler. I run
the scripts from a mingw bash shell.
The following problems occur:
-
Twan van Laarhoven wrote:
I am having some problems with the latest builds of GHC on windows. For
some reason ghc has decided to use backslashes in filenames. This leads
to problems when building the stage libraries and the stage 2 compiler.
I run the scripts from a mingw bash shell.
After
Hello GHC people,
I was trying my hand at some GHC hacking, and I couldn't help but notice
that much of the code looks (IMHO) horrible. There are some things that look
as if they haven't been touched since the Haskell 1.3 days. The most
striking is the use of `thenXX` instead of do notation.
Simon Peyton-Jones wrote:
Concerning (b) here's a suggestion. As now, require that every instance
requires an instance declaration. So, in the main example of
http://haskell.org/haskellwiki/Class_system_extension_proposal, for a new data
type T you'd write
instance Monad T where
Hello,
I noticed there is a difference in generalized newtype deriving between
6.6 and 6.8. In GHC 6.4.1 the following:
{-# LANGUAGE GeneralizedNewtypeDeriving #-}
import Control.Monad.Error
newtype MyMonad m a = MyMonad (m a)
deriving (Monad, MonadError String)
correctly gives a
17 matches
Mail list logo
