On 20/08/2012, at 11:19 PM, Johannes Waldmann wrote:
> Are there any Haskell bindings for BDD libraries
> (reduced ordered binary decision diagrams)?
>
> E.g., it seems "buddy" is commonly used
> http://packages.debian.org/squeeze/libbdd-dev
> and it has an Ocaml binding.
My hBDD bindings are on
Also, I have to admit I was a bit handwavy here; I meant P in a
metatheoretic sense, that is "P(a) is some type which contains 'a' as a
free variable", and thus the 'theorem' is really a collection of theorems
parametrized on the P you choose.
For example, P(a) could be "Show a & a -> Int"; in tha
Hello,
I also completely agree with Bryan's point which is why I usually don't add
upper bounds on the dependencies of the packages that I maintain---I find
that the large majority of updates to libraries tend to be backward
compatible, so being optimistic seems like a good idea.
By the way, some
It seems really hard to solve this, since the type checker works before
instance selection has had a chance to do anything.
Instead of looking at the instance declaration, look at the use site:
lift x
expects the argument to have type
x :: t m a
for some t :: (* -> *) -> * -> *, m :: * -
On Mon, 20 Aug 2012, Francesco Mazzoli wrote:
Hi list(s),
I've been hooked on Haskell for a while now (some of you might know me as
bitonic on #haskell), and I find myself to decide on a project for my masters
thesis.
Inspired by the David Terei's master thesis (he wrote the LLVM backend),
Hi all,
Just passing on this job opportunity for another company. SQream is
looking for Haskellers located in Israel. They are working on high
performance solutions for large databases using Haskell. If you're
interested, please contact me off-list, and I'll pass your information
along.
Thanks,
M
2012/8/20 Johannes Waldmann :
> Are there any Haskell bindings for BDD libraries
> (reduced ordered binary decision diagrams)?
>
> E.g., it seems "buddy" is commonly used
> http://packages.debian.org/squeeze/libbdd-dev
> and it has an Ocaml binding.
>
> Yes, there is http://hackage.haskell.org/pack
Hi list(s),
I've been hooked on Haskell for a while now (some of you might know me as
bitonic on #haskell), and I find myself to decide on a project for my masters
thesis.
Inspired by the David Terei's master thesis (he wrote the LLVM backend), I was
wondering if there were any projects requiring
On Thu, Aug 16, 2012 at 06:07:06PM -0400, Joey Adams wrote:
> On Wed, Aug 15, 2012 at 3:38 PM, Bryan O'Sullivan wrote:
> > I propose that the sense of the recommendation around upper bounds in the
> > PVP be reversed: upper bounds should be specified only when there is a known
> > problem with a n
Of course if you wish or need to upgrade a package then you can just upgrade
it -- I am not suggesting anyone should forgo upgrades! It is just that
there is no need to make the stability of a build process dependent on new
package releases.
To upgrade a package I would fork my sandbox, hack away
My two (or three) cents:
- Given a choice between a world where there is tedious work for package
maintainers vs. a world where packages randomly break for end users (giving
them a bad impression of the entire Haskell ecosystem), I choose the former.
- More automation can ease the bur
Hub looks interesting, I'll have to try it out (though I'm not on an
RPM based distro). But isn't this the goal of things like semantic
versioning [0] and the PVP? To know that you can safely upgrade to a
bugfix release, and relavily safely to a minor release, but on a major
release, you have to ta
On 15/08/2012 21:44, Johan Tibell wrote:
On Wed, Aug 15, 2012 at 1:02 PM, Brandon Allbery wrote:
So we are certain that the rounds of failures that led to their being
*added* will never happen again?
It would be useful to have some examples of these. I'm not sure we had
any when we wrote the
Are there any Haskell bindings for BDD libraries
(reduced ordered binary decision diagrams)?
E.g., it seems "buddy" is commonly used
http://packages.debian.org/squeeze/libbdd-dev
and it has an Ocaml binding.
Yes, there is http://hackage.haskell.org/package/obdd
but I need better performance (with
I think we should encourage stable build environments to know precisely
which package versions they have been using and to keep using them until
told otherwise. Even when the types and constraints all work out there is a
risk that upgraded packages will break. Everybody here wants cabal to just
ins
Untested, but this should be about right:
osi (Bij f b) = iso (Bij b f)
Erik
On Mon, Aug 20, 2012 at 2:35 PM, Sergey Mironov wrote:
> Hi. I'm porting old code, which uses fclabels <0.5. Old fclabels
> define Iso typeclass as follows:
>
> class Iso f where
> iso :: a :<->: b -> f a -> f b
>
Hi. I'm porting old code, which uses fclabels <0.5. Old fclabels
define Iso typeclass as follows:
class Iso f where
iso :: a :<->: b -> f a -> f b
iso (Lens a b) = osi (b <-> a)
osi :: a :<->: b -> f b -> f a
osi (Lens a b) = iso (b <-> a)
Newer one defines iso:
class Iso (~>) f where
On Aug 19, 2012, at 10:40 , Heinrich Apfelmus wrote:
> Doaitse Swierstra wrote:
>> Over the years we have been constructing a collection of Embedded
>> Domain Specific Languages for describing compilers which are
>> assembled from fragments which can be compiled individually. In this
>> way one
I am strongly against this, especially for packages in the platform.
If you fail to specify an upper bound, and I depend on your package,
your dependencies can break my package! For example, say I develop
executable A and I depend on library B == 1.0. Library B depends on
library C >= 0.5 (no uppe
19 matches
Mail list logo
