Re: [Haskell-cafe] Class constraints with free type variables and fundeps
At Fri, 28 Sep 2012 18:33:23 -0700, Alexander Solla wrote: Only with respect to type inference. I don't understand this comment. I wouldn't have replied with that line of thought if you had just told us what the problem was in the first place. I /was/ saying that you can use explicit type annotations to disambiguate instances. Most of us haven't memorized the Haskell 2010 report. We let the compiler tell us what's wrong and either learn why, or how to fix it. So post your errors. Sorry, I posted in a hurry. Besides, feeding those lines to a compiler before replying takes 10 seconds. By the way, it is rather rude to publicly post a private email... I thought that you had forgot to reply all, as often happens. I also want the discussion to stay on the list, so that people can read in the future. I'm sorry if that email was meant to be private, I saw nothing private about it. Now, on to your real problem. Use TypeFamilies instead: class Foo a where type BarThing a :: * class Foo a = Bar a where foo :: a - BarThing a - b As I mentioned in the original post, `Foo' is outside my control. This is pretty pointless, since you can just refactor into the nearly equivalent: class Foo a class Foo a = Bar a where type BarThing a :: * foo :: a - BarThing a - c It may or may not matter to which family the type synonym belongs. Mine was a contrived example to show the issue. The whole point is to reduce the number of arguments of a class by referring to another class and its fundeps. What is the problem you are actually trying to solve? What I actually (would like to) have is something like this: class (EditDistance algo sym, ListLike full sym) = Search container full algo | container - full, container - algo where methods referencing `sym' This limitation is annoying even without referencing `sym' (which I can avoid to do) since is prevents me from putting constraints that express what the purpose of the class is and will have to be repeated in every instance. Then I'd also like to have newtype TST sym algo = ... instance (Ord sym, ListLike full sym) = Search (TST sym algo) full algo This one is a different problem - it requires UndecidableInstances and I don't understand why. It seems to me that the coverage condition (http://www.haskell.org/ghc/docs/latest/html/users_guide/type-class-extensions.html, point 7.6.3.2) is too strict in these cases. But this is not that important. -- Francesco * Often in error, never in doubt ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Class constraints with free type variables and fundeps
At Sat, 29 Sep 2012 10:30:07 +0200, Francesco Mazzoli wrote: Then I'd also like to have newtype TST sym algo = ... instance (Ord sym, ListLike full sym) = Search (TST sym algo) full algo This one is a different problem - it requires UndecidableInstances and I don't understand why. It seems to me that the coverage condition (http://www.haskell.org/ghc/docs/latest/html/users_guide/type-class-extensions.html, point 7.6.3.2) is too strict in these cases. But this is not that important. This doesn't make sense with the code posted (which would require sensibly UndecidableInstances), I meant something like this (I don't have actual code to show the problem): data Foo a class Bar a b | a - b class Quux a b | a - b instance Bar a b = Quux (Foo a) b -- Francesco * Often in error, never in doubt ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Class constraints with free type variables and fundeps
Well, it seems that you can't do exactly what you want. So, the simplest way to
do this would be not to make Foo a superclass for Bar:
class Bar a where
foo :: Foo a b = a - b - c
Then you would have to mention Foo everywhere.
If you really need, for some reason, to ensure that every Bar instance has a
corresponding Foo instance, you can do some oleging this way:
data Void b = Void
data FooEv a where FooEv :: Foo a b = Void b - FooEv a
class Bar a where
barFoo :: FooEv a
bar :: Foo a b = a - b - c
Then, whenever you need Foo methods, you can do pattern-matching:
case barFoo :: FooEv a of
FooEv (Void :: Void b) - …
Now some b is in scope, and there is an instance of Foo a b.
On Sep 28, 2012, at 8:36 PM, Francesco Mazzoli f...@mazzo.li wrote:
I would expect this to work, maybe with some additional notation (a la
ScopedTypeVariables)
{-# LANGUAGE FunctionalDependencies #-}
{-# LANGUAGE MultiParamTypeClasses #-}
class Foo a b | a - b
class Foo a b = Bar a where
foo :: a - b - c
The type family equivalent works as expected:
{-# LANGUAGE TypeFamilies #-}
class Foo a where
type T a :: *
class Bar a where
foo :: a - T a - c
I can't use type families because the `Foo' I'm using is in an external
library.
Is there any way to achieve what I want without adding `b' to `Bar'?
--
Francesco * Often in error, never in doubt
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Class constraints with free type variables and fundeps
At Sat, 29 Sep 2012 13:04:59 +0400, MigMit wrote: Well, it seems that you can't do exactly what you want. So, the simplest way to do this would be not to make Foo a superclass for Bar: class Bar a where foo :: Foo a b = a - b - c Then you would have to mention Foo everywhere. Just to clarify, I already worked my way around that problem. I want to know why I can't do it since it seems a useful feature to have. In fact, I was doing something very similar to what you're proposing before, but I think having the additional argument is better in my code, for various reasons. You can check the actual class here: https://github.com/bitonic/language-spelling/blob/c3b1fa3014983acf41f9248c9507d7404424/Language/Distance/Search/Class.hs, I've left the old version commented. If you really need, for some reason, to ensure that every Bar instance has a corresponding Foo instance, you can do some oleging this way: data Void b = Void data FooEv a where FooEv :: Foo a b = Void b - FooEv a class Bar a where barFoo :: FooEv a bar :: Foo a b = a - b - c Then, whenever you need Foo methods, you can do pattern-matching: case barFoo :: FooEv a of FooEv (Void :: Void b) - … Now some b is in scope, and there is an instance of Foo a b. Well, I'm sure there are endless ways to get around this, but in cases like this the resulting mess far outweighs the advantages :). -- Francesco * Often in error, never in doubt ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Class constraints with free type variables and fundeps
At Sat, 29 Sep 2012 10:56:29 +0200, Francesco Mazzoli wrote: At Sat, 29 Sep 2012 10:30:07 +0200, Francesco Mazzoli wrote: Then I'd also like to have newtype TST sym algo = ... instance (Ord sym, ListLike full sym) = Search (TST sym algo) full algo This one is a different problem - it requires UndecidableInstances and I don't understand why. It seems to me that the coverage condition (http://www.haskell.org/ghc/docs/latest/html/users_guide/type-class-extensions.html, point 7.6.3.2) is too strict in these cases. But this is not that important. This doesn't make sense with the code posted (which would require sensibly UndecidableInstances), I meant something like this (I don't have actual code to show the problem): data Foo a class Bar a b | a - b class Quux a b | a - b instance Bar a b = Quux (Foo a) b Actually I know why this is the case - instances are picked without looking at the constraints, and there is no backtracking. I guess my brain just can't resist from seeing Prolog in type classes... -- Francesco * Often in error, never in doubt ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Discovery of unnecessary build-depends
On 28 September 2012 19:29, Jason Whittle ja...@funnelfire.com wrote: Is there a tool available that will tell me if the cabal file for my library or application has any unnecessary build-depends? FWIW, I felt the need for such a tool many times before too. The same tool can also report outdated dependencies, maybe? Cheers, Ozgur ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Class constraints with free type variables and fundeps
On Fri, Sep 28, 2012 at 6:36 PM, Francesco Mazzoli f...@mazzo.li wrote:
I would expect this to work, maybe with some additional notation (a la
ScopedTypeVariables)
{-# LANGUAGE FunctionalDependencies #-}
{-# LANGUAGE MultiParamTypeClasses #-}
class Foo a b | a - b
class Foo a b = Bar a where
foo :: a - b - c
The type family equivalent works as expected:
{-# LANGUAGE TypeFamilies #-}
class Foo a where
type T a :: *
class Bar a where
foo :: a - T a - c
I can't use type families because the `Foo' I'm using is in an external
library.
Is there any way to achieve what I want without adding `b' to `Bar'?
I was browsing the GHC bug tracker and accidentally might have found a
solution to your problem:
http://hackage.haskell.org/trac/ghc/ticket/7100
Basically you have to make a type family to recapitulate the
functional dependencies in the instances of Foo:
type family FooFD a
-- for each instance Foo A B, you have to write:
-- type instance FooFD A = B
class Foo a (FooFD a) = Bar a where
foo :: a - FooFD a - c
Anywhere you would use 'b', you use the type family instead.
The example in the ticket also had a 'b ~ FooFD a' superclass
constraint on Foo itself, which you can't add if you don't control
Foo, but I'm not sure what it's necessary for - in my brief tests
removing it didn't cause problems.
A weakness of this approach is that you have to manually add a type
instance for every instance of Foo, which may or may not be a problem
in your situation.
--
Francesco * Often in error, never in doubt
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
--
Your ship was destroyed in a monadic eruption.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Class constraints with free type variables and fundeps
On Sep 29, 2012, at 9:49 PM, Gábor Lehel illiss...@gmail.com wrote:
On Fri, Sep 28, 2012 at 6:36 PM, Francesco Mazzoli f...@mazzo.li wrote:
I would expect this to work, maybe with some additional notation (a la
ScopedTypeVariables)
{-# LANGUAGE FunctionalDependencies #-}
{-# LANGUAGE MultiParamTypeClasses #-}
class Foo a b | a - b
class Foo a b = Bar a where
foo :: a - b - c
The type family equivalent works as expected:
{-# LANGUAGE TypeFamilies #-}
class Foo a where
type T a :: *
class Bar a where
foo :: a - T a - c
I can't use type families because the `Foo' I'm using is in an external
library.
Is there any way to achieve what I want without adding `b' to `Bar'?
I was browsing the GHC bug tracker and accidentally might have found a
solution to your problem:
http://hackage.haskell.org/trac/ghc/ticket/7100
Basically you have to make a type family to recapitulate the
functional dependencies in the instances of Foo:
type family FooFD a
Actually, I think it's better to use a class here:
class Foo a (FooFD a) = FooProxy a where type FooFD a
-- for each instance Foo A B, you have to write:
-- type instance FooFD A = B
class Foo a (FooFD a) = Bar a where
foo :: a - FooFD a - c
Anywhere you would use 'b', you use the type family instead.
The example in the ticket also had a 'b ~ FooFD a' superclass
constraint on Foo itself, which you can't add if you don't control
Foo, but I'm not sure what it's necessary for - in my brief tests
removing it didn't cause problems.
A weakness of this approach is that you have to manually add a type
instance for every instance of Foo, which may or may not be a problem
in your situation.
--
Francesco * Often in error, never in doubt
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
--
Your ship was destroyed in a monadic eruption.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Class constraints with free type variables and fundeps
At Sat, 29 Sep 2012 19:49:36 +0200, Gábor Lehel wrote: I was browsing the GHC bug tracker and accidentally might have found a solution to your problem: http://hackage.haskell.org/trac/ghc/ticket/7100 Thanks, this makes me feel better. What interested me is not the workarounds, that I had already partly explored, but why the limitation is there in the first place. It turns out that it's because it'd add complexity and type families do it better. Fair enough. Basically you have to make a type family to recapitulate the functional dependencies in the instances of Foo: type family FooFD a -- for each instance Foo A B, you have to write: -- type instance FooFD A = B class Foo a (FooFD a) = Bar a where foo :: a - FooFD a - c Anywhere you would use 'b', you use the type family instead. The example in the ticket also had a 'b ~ FooFD a' superclass constraint on Foo itself, which you can't add if you don't control Foo, but I'm not sure what it's necessary for - in my brief tests removing it didn't cause problems. A weakness of this approach is that you have to manually add a type instance for every instance of Foo, which may or may not be a problem in your situation. I think this method, while useful to show the already shown relation between fundeps and type families, is pointless in reality. The most convenient method in practice, by far, is just to add the dependent part of the fundep explicitly to Bar. Along to the awkwardness you already pointed out of having to declare the family instance for each type, I'm introducing some unfamiliar and unnecessary type family to the user. It adds nothing but confusion. Not to mention that if I stick to fundeps I might hope to use my code with something else apart from GHC. -- Francesco * Often in error, never in doubt ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANNOUNCE: bindings-gobject-0.4
Hello, I uploaded new release of bindings-gobject, low level binding to gobject library: http://hackage.haskell.org/package/bindings-gobject-0.4 (I maintain it now) Now it exposes internals of GObject and GObjectClass, so it is possible to create custom GObject subclasses from haskell land. Source repository contains basic example: https://github.com/Yuras/bindings-gobject/blob/master/examples/custom-object/main.hs The use case I'm personally is interested in is implementing custom SourceCompletionProvider for gtksourceview2. I hope it will be useful for other applications. Right now we don't (afaik) have low level bindings to gtk and gtksourceview. But once we will have them, it will be possible to create custom controls in haskell and even expose them to C (C++, python, etc) land. Thanks, Yuras ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] One of the new buzz phrases is Event-Sourcing; is Haskell suitable for this?
http://martinfowler.com/eaaDev/EventSourcing.html http://martinfowler.com/articles/lmax.html -- -- Regards, KC ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] If I want to make a pure Haskell eigenvalue, etc. package without calling to LAPACK, etc ...
What are some good basis (pun intended) to start from? e.g. REPA? or ? -- -- Regards, KC ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] One of the new buzz phrases is Event-Sourcing; is Haskell suitable for this?
On Sat, Sep 29, 2012 at 8:46 PM, KC kc1...@gmail.com wrote: http://martinfowler.com/eaaDev/EventSourcing.html STM? And I believe there's work on the debugger in ghci to run programs backwards. -- brandon s allbery allber...@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] One of the new buzz phrases is Event-Sourcing; is Haskell suitable for this?
It´´s a very iteresting concept. The Workflow Monad transformer [1], in Control.Workflow perform logging and recovery of application istate from the log created. It has no implementation of roll-back or limited recovery upto a point, but this is easy to implement. It also has many inspection and synchronization primitives. It has been used also for translating the log of a program and recovering the state in another machine. The log can be pretty-printed for debugging. [1] http://hackage.haskell.org/package/Workflow 2012/9/30 KC kc1...@gmail.com: http://martinfowler.com/eaaDev/EventSourcing.html http://martinfowler.com/articles/lmax.html -- -- Regards, KC ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Alberto. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Monads
Hello, I would an examples of monads that are pure, i.e. no side-effects. Thank you, Vasili ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Monads
You have fallen into the misconception that monads are impure, they are not. Many monad tutorials begin (erroneously) with the lines monads allow you to do impure programming in Haskell. This is false, monads are pure, it's IO that's impure, not the monadic programming style. Monads let you *emulate* an impure style in pure code, but it's nothing more than this: an emulation. So in summary you can take any monad you want, and it will be pure, however it's underlying implementation may not be (such is the case with IO, for example). Consider any of: -- State, -- List, -- Cont, -- ... literally any monad, some may be more obviously pure than others, but hey, people say that about me all the time. kris On Sat, Sep 29, 2012 at 9:57 PM, Vasili I. Galchin vigalc...@gmail.com wrote: Hello, I would an examples of monads that are pure, i.e. no side-effects. Thank you, Vasili ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Monads
From: http://www.haskell.org/haskellwiki/Monad The computation doesn't have to be impure and can be pure itself as well. Then monads serve to provide the benefits of separation of concerns, and automatic creation of a computational pipeline. On Sat, Sep 29, 2012 at 6:57 PM, Vasili I. Galchin vigalc...@gmail.com wrote: Hello, I would an examples of monads that are pure, i.e. no side-effects. Thank you, Vasili ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- -- Regards, KC ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Call for discussion: OverloadedLists extension
On 9/28/12 2:48 PM, Mario Blažević wrote: On 12-09-26 08:07 PM, wren ng thornton wrote: On 9/25/12 1:57 PM, Sjoerd Visscher wrote: Maybe we could make a literal [a,b,c] turn into unpack [a,b,c]# where [a,b,c]# is a statically-allocated vector? I'm kinda surprised this isn't already being done. Just doing this seems like it'd be a good undertaking, regardless of whether we get overloaded list literals. Just storing the literal as a C-like array and inflating it to a list/array/vector at runtime seems like it should be a big win for code that uses a lot of literals. Why? I'm surprised that this is an issue at all. If list literals you are talking about are constant, wouldn't GHC apply constant folding and construct the list only the first time it's needed? The problem is: if the list is stored naively in the .data segment (as apparently it is), then we have to store all the pointer structure as well as the data. This hugely bloats the disk footprint for programs. That is, all the reasons why String=[Char] is bad at runtime are also reasons why this representation is bad at objectcode time. For most lists, the pointer structure is a considerable portion of the total memory cost. During runtime this overhead is (or at least may be) unavoidable due to the dynamic nature of program execution; but there's no reason to have this overhead in the compiled format of the program since it's trivial to generate it from a compact representation (e.g., storing lists as C-style arrays + lengths). The only conceivable benefit of storing lists on disk using their heap representation is to allow treating the .data segment as if it were part of the heap, i.e., to have zero-cost inflation and to allow GC to ignore that part of the heap. However, for lists, I can't imagine this actually being beneficial in practice. This sort of thing is more beneficial for large structures of static data (e.g., sets, maps,...). But then for large static data, we still usually want a non-heap representation (e.g., cache-oblivious datastructures), since we're liable to only look at the data rather than to change it. It's only when we have lots of static mutable data that it makes sense to take heap snapshots. -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
