Hello,
> It's something I've wanted... Got a link for hereditary Harrop formulas
> so I can add them to my to-implement-when-Qhc-is-good-enough list?
> Google isn't telling me much about them except how to add support for
> constaints, which isn't terribly helpful.
>
This paper has a good descript
On Wed, Aug 01, 2007 at 05:29:19PM -0700, Conal Elliott wrote:
> Sadly, this solution runs into the problem of instance selection based only
> on head-matching, not back-chaining into constraints. For instance, I'd
> like also to use the following "conflicting" declaration.
>
> instance (Appl
I'm developing a type constructor class and want the constraint forall a.
Monoid (m a) (where m :: * -> *), which is neither legal Haskell, nor
supported by GHC.
As a work-around, I used the first encoding suggested in "Simulating
Quantified Class Constraints" (Valery Trifonov, Haskell Workshop '0
Apologies if you received multiple copies of this message
CALL FOR BOOK CHAPTERS
BOOK TITLE:
Process Algebra for Parallel and Distributed Processing:
Algebraic Languages in Specification-Based Software Development
EDITORS:
Michael Alexander, WU Wien
Bill Gardner, University of Guelph
The boo
On 8/1/07, apfelmus <[EMAIL PROTECTED]> wrote:
> There are some fundamental problems/design choices for type classes
> in conjunction with separate compilation/modularity that need to be
> researched before trying anything like that. In particular, any
> ad-hoc Prolog, CHR or -fallow-undecidable-i
On 7/31/07, jeff p <[EMAIL PROTECTED]> wrote:
> Hello,
> > My understanding is that this sort of instance collection doesn't
> > work together because instance selection is based only on the
> > matching the head of an instance declaration (part after the
> > "=>"). I'm wondering why not use the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
- -BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Wolfgang,
Why did Gofer have this power while Haskell does not?
Quite probably they never bothered to test it.
More probably ;-) they did test it and just swept it under the carpet
in order not
Am Mittwoch, 1. August 2007 14:41 schrieb apfelmus:
> […]
> The problem with the Functor/Cofunctor instances is that they are
> ambiguous as soon as a type constructor X is made an instance of both
> Functor and Cofunctor . Of course, such an X cannot exist in a
> mathematically useful way
Conal Elliott wrote:
> I keep running into situations in which I want more powerful search in
> selecting type class instances. One example I raised in June, in which all
> of the following instances are useful.
>
>> instance (Functor g, Functor f) => Functor (O g f) where
>> fmap h (O gf) = O
|My understanding is that this sort of instance collection doesn't work together because instance
selection is based only on the matching the head of an instance declaration (part after the "=>").
I'm wondering why not use the preconditions as well, via a Prolog-like, backward-chaining search for
Simon Peyton-Jones <[EMAIL PROTECTED]> wrote:
> It certainly makes sense to do backward chaining, but I don't know any
> Haskell implementation
> that's tried it. It'd be more complicated in the presence of functional
> dependencies, since we
> must "undo" any unifications done as a result of d
If only for those watching from home, here are some references.
jeff p <[EMAIL PROTECTED]> wrote in article <[EMAIL PROTECTED]> in
gmane.comp.lang.haskell.general:
> >Better yet,
> > how about LambdaProlog (
> > http://www.lix.polytechnique.fr/Labo/Dale.Miller/lProlog),
> > which generalizes from
Conal
It certainly makes sense to do backward chaining, but I don't know any Haskell
implementation that's tried it. It'd be more complicated in the presence of
functional dependencies, since we must "undo" any unifications done as a result
of discarded searches, much like the "trail" in a Pro
13 matches
Mail list logo
