At Mon, 27 Jun 2011 15:02:33 +0100,
Paterson, Ross wrote:
There is no a priori reason why b should depend on a in a pair of
bindings such as these:
a = const (\x - x) b
b = const (a :: Int - Int) (a :: Bool - Bool)
There is: section 3.16 says that in an expression type
At Sun, 26 Jun 2011 23:25:31 +1200,
Anthony Clayden wrote:
Totally brilliant, and almost impenetrable.
If I understand what's going on (big IF), I'm wondering a
few things:
- You've used type-level NAT to encode the type.
What if two different types get encoded as the same NAT?
In
The Haskell 2010 report contains ambiguous and sometimes contradictory
definitions of the terms simple pattern binding and declaration
group. The confusion is compounded by the phrasing of the
monomorphism restriction, which is carried over from the Haskell98
report in which a different
At Mon, 27 Jun 2011 00:06:09 +0100,
Paterson, Ross wrote:
I don't believe the definition of depends in Section 4.5.1 needs
to change. The Report consistently uses expression type signature
for the expression and type signature for the declaration, so it is
clear that the latter is meant
At Thu, 23 Jun 2011 00:40:38 -0700 (PDT),
o...@okmij.org wrote:
How would you make this safe for dynamic loading? Would you have to
keep track of all the package/module names that have been linked into
the program and/or loaded, and not allow duplicates? Is dynamic
unloading of code
At Tue, 21 Jun 2011 00:35:46 -0700 (PDT),
o...@okmij.org wrote:
I have implemented type-level TYPEREP (along with a small library for
higher-order functional programming at the type level). Overlapping
instances may indeed be avoided. The library does not use functional
dependencies
At Fri, 17 Jun 2011 13:21:41 +,
Simon Peyton-Jones wrote:
Concerning 1. mutual dependencies I believe that equality
superclasses provide the desired expressiveness. The code may not
look quite as nice, but equality superclasses (unlike fundeps) will
play nicely with GADTs, type
At Wed, 15 Jun 2011 10:36:46 +,
Simon Peyton-Jones wrote:
The issue doesn't even arise with type families:
class MonadState m where
type State m :: *
instance MonadState m = MonadState (MaybeT m) where
type State (MaybeT m) = State m
So examples that
At Tue, 14 Jun 2011 19:52:00 -0700 (PDT),
o...@okmij.org wrote:
Dan Doel wrote:
class C a b | a - b where
foo :: a - b
foo = error Yo dawg.
instance C a b where
The instance 'C a b' blatantly violates functional dependency and
should not have been accepted. The
At Tue, 14 Jun 2011 09:36:41 +,
Simon Peyton-Jones wrote:
5. David wants a wiki page fixed. But which one? And how is it locked
down?
This page:
http://hackage.haskell.org/trac/haskell-prime/wiki/FunctionalDependencies
Currently under cons for FunctionalDependencies, it
At Tue, 14 Jun 2011 10:40:48 -0400,
Dan Doel wrote:
1. As things stand in GHC you can do some things with functional
dependencies that you can't do with type families. The archetypical example
is type equality. We cannot write
type family Eq a b :: *
type instance Eq k
At Tue, 14 Jun 2011 12:31:47 -0400,
Dan Doel wrote:
Sorry about the double send, David. I forgot to switch to reply-all in
the gmail interface.
Okay. I don't really write a lot of code like this, so maybe I missed
the quirks.
In that case, HList has been relying on broken behavior of
Thanks for the responses. I realized after sending the message that
it wasn't clear exactly what I was advocating, which is probably more
modest that what people are thinking.
Mostly I was hoping the AssociatedTypes wiki page could be updated to
reflect that AssociatedTypes can't replace
At Sun, 29 May 2011 19:35:15 -0400,
Dan Doel wrote:
On Sun, May 29, 2011 at 6:45 PM, Ben Millwood hask...@benmachine.co.uk
wrote:
1) Disallow the overlapping instance C Int Char, because it is
incompatible with the C Int Int from the other module. This is what
GHC 7 seems to do.
This
14 matches
Mail list logo
