nderlying concern: we are losing valuable
> members of the community not because of the technical decisions that are
> being made, but because of the process by which they are being made.
> That concern is what drove my proposals. It is perfectly valid to think
> that that loss was the i
Hello,
I'm Dan Doel. I'm on the core libraries committee (though I'm speaking
only for myself). As I recall, one of the reasons I got tapped for it
was due to my having some historical knowledge about Haskell; not
because I was there, but because I've gone back and looked at
On Wed, Jul 10, 2013 at 3:08 AM, Andreas Abel wrote:
> Another instance (cut-down) are let-guards like
>
> let Just x | x > 0 = e in x
>
> The "x > 0" is understood as an assertion here, documenting an invariant.
> However, Haskell reads this as
>
> let Just x = case () of { () | x > 0 -> e }
about MPTCs alone that would be a problem, though.
On Sun, Dec 2, 2012 at 2:56 PM, Gábor Lehel wrote:
> On Sun, Dec 2, 2012 at 7:06 PM, Dan Doel wrote:
> > This is a significant problem for even some of the more ubiquitous
> > extensions. For instance, there are multiple comp
This is a significant problem for even some of the more ubiquitous
extensions. For instance, there are multiple compilers that implement
RankNTypes, but I would not be surprised at all if programs using that
extension were not portable across implementations (they're not really even
portable across
On Tue, Jun 14, 2011 at 9:56 PM,
wrote:
> Maybe "functional dependencies" is a poor name. I'm not going to
> argue it's a good one, just that the extension is quite useful.
> Despite what the name suggests, it is most useful to think of
> "| a b -> c d" as meaning "any method that uses types a an
On Wed, Jun 15, 2011 at 3:25 AM, Simon Peyton-Jones
wrote:
> Wait. What about
> instance C [a] [b]
> ? Should that be accepted? The Coverage Condition says "no", and indeed it
> is rejected. But if you add -XUndecidableInstances it is accepted.
This 'clearly' violates the functional de
On Tue, Jun 14, 2011 at 5:38 PM,
wrote:
> Undecidable instances are orthogonal to both FunctionalDependencies
> and OverlappingInstances. They concern whether or not the compiler
> can guarantee that the typechecker will terminate. You can have
> undecidable instances without either of the other
On Tue, Jun 14, 2011 at 1:19 PM,
wrote:
> No, these are not equivalent. The first one "TypeEq a b c" is just
> declaring an instance that works "forall c". The second is declaring
> multiple instances, which, if there were class methods, could have
> different code. The second one is illegal, b
Sorry about the double send, David. I forgot to switch to reply-all in
the gmail interface.
On Tue, Jun 14, 2011 at 11:49 AM,
wrote:
> You absolutely still can use FunctionalDependencies to determine type
> equality in GHC 7. For example, I just verified the code below with
> GHC 7.02:
>
> *Main
On Tue, Jun 14, 2011 at 11:27 AM, Andrea Vezzosi wrote:
>> class C a b | a -> b
>> instance C a R
>> instance C T U
>
> Are you sure that worked before?
80%
> The following still does anyhow:
>
> data R
> data T
> data U
> class C a b | a -> b
> instance TypeCast R b => C
On Tue, Jun 14, 2011 at 5:36 AM, Simon Peyton-Jones
wrote:
> There was an interesting thread on haskell-prime [1], about the relationship
> between functional dependencies and type families. This message is my
> attempt to summarise the conclusions of that thread. I'm copying other
> interest
On Sun, May 29, 2011 at 6:45 PM, Ben Millwood wrote:
> It would seem very strange to me if haskell-prime made the choice of
> fundeps/type families based on the behaviour with
> OverlappingInstances. I'm under the impression that Overlapping is
> generally considered one of the more controversial
On Tuesday 04 January 2011 5:24:21 am o...@okmij.org wrote:
> Method A: just define bind as usual
>
> > instance (Functor (Iteratee el m),Monad m) => Monad (Iteratee el m) where
> >
> > return = IE_done
> >
> > IE_done a >>= f = f a
> > IE_cont e k >>= f = IE_cont e (\s -> k s
On Monday 08 February 2010 11:18:07 am Simon Peyton-Jones wrote:
> I think that Hugs is right here. After all, there is no ambiguity in any
> of these expressions. And an application-domain user found this behaviour
> very surprising.
I think it's clear what one would expect the result of thes
On Thursday 24 April 2008, Wolfgang Jeltsch wrote:
> I don’t think that this is reasonable. (.) corresponds to the little
> circle in math which is a composition. So (.) = (<<<) would be far better.
Were I building a library, this might be the direction I'd take things.
They're two incompatible
On Wednesday 23 April 2008, Chris Smith wrote:
> I don't think I agree that fail in the Monad typeclass is a good example
> here, or necessarily that there is a good example.
>
> We should remember that there is a cohesive community of Haskell
> programmers; not a bunch of unrelated individuals who
On Wednesday 23 April 2008, Bulat Ziganshin wrote:
> it's not refactoring! it's just adding more features - exception
> handler, progress indicator, memory pool and so on. actually, code
> blocks used as a sort of RAII for Haskell. are you wanna change all
> those ';' when you add new variable to y
On Wednesday 23 April 2008, Bulat Ziganshin wrote:
> Hello Dan,
>
> Wednesday, April 23, 2008, 1:42:20 PM, you wrote:
> > This wouldn't work, you'd have to rewrite it as:
> >
> > withSomeResource foo .
> > withSomeOtherThing bar .
> > yetAnotherBlockStructured thing $ ...
>
> it i
On Wednesday 23 April 2008, Duncan Coutts wrote:
> withSomeResource foo $
> withSomeOtherThing bar $
> yetAnotherBlockStructured thing $ ...
>
> Does that work?
This wouldn't work, you'd have to rewrite it as:
withSomeResource foo .
withSomeOtherThing bar .
yetAnotherBlock
On Tuesday 22 April 2008, Simon Marlow wrote:
> I'm hoping someone will supply some. There seemed to be strong opinion
> on #haskell that this change should be made, but it might just have been
> a very vocal minority.
These are the arguments off the top of my head:
1) Anything of the form:
21 matches
Mail list logo
