On 25 Apr 2008, at 15:38, Tom Schrijvers wrote:
Prolog works under the assumption of a closed world. That's
contrary to the open world view of regular type classes. So these
aren't the intended semantics.
By which I gather you mean the interpretation of ":-" as logical
connective "=>" rat
On Fri, 25 Apr 2008, Hans Aberg wrote:
On 25 Apr 2008, at 14:20, Tom Schrijvers wrote:
Prolog works under the assumption of a closed world. That's contrary to the
open world view of regular type classes. So these aren't the intended
semantics.
By which I gather you mean the interpretation o
On 25 Apr 2008, at 14:20, Tom Schrijvers wrote:
Prolog works under the assumption of a closed world. That's
contrary to the open world view of regular type classes. So these
aren't the intended semantics.
By which I gather you mean the interpretation of ":-" as logical
connective "=>" rat
On Fri, 25 Apr 2008, Hans Aberg wrote:
On 18 Apr 2008, at 20:04, Martin Sulzmann wrote:
Let's consider our running example
class D a b | a -> b
instance D a b => D [a] [b]
which we can write in CHR notation
D a b, D a c ==> b=c(FD)
D [a] [b] <=> D a b (Inst)
These rules overlap.
On 18 Apr 2008, at 20:04, Martin Sulzmann wrote:
Let's consider our running example
class D a b | a -> b
instance D a b => D [a] [b]
which we can write in CHR notation
D a b, D a c ==> b=c(FD)
D [a] [b] <=> D a b (Inst)
These rules overlap.
I experimented with translations into
I now recall the reason for NOT using
D a b, D [a] c ==> c = [b]
The reason is that the above rule
creates a new critical pair with
instance D a b => D [a] [b]
To resolve the critical pair we need yet another rule
D a b, D [[a]] c ==> c =[[b]]
You can already see where this leads to.
In g
BTW, here's a non-contrived example. It's pretty easy to come up with
examples when you try to use type classes instead of a proper module system.
Here we have expressions parametrized over how identifiers and literals are
represented. First a simple instance, and then one where all the types ar
Lennart Augustsson wrote:
I've never thought of one being shorthand for the other, really.
Since they are logically equivalent (in my interpretation) I don't
really care which one we regard as more primitive.
True. See my response to Iavor's recent email.
Martin
__
Thanks Iavor! Things become now clear.
Let's consider our running example
class D a b | a -> b
instance D a b => D [a] [b]
which we can write in CHR notation
D a b, D a c ==> b=c(FD)
D [a] [b] <=> D a b (Inst)
These rules overlap.
Let's consider the critical pair
D [a] [b], D [a]
I've never thought of one being shorthand for the other, really.
Since they are logically equivalent (in my interpretation) I don't really
care which one we regard as more primitive.
On Fri, Apr 18, 2008 at 9:26 AM, Martin Sulzmann <[EMAIL PROTECTED]>
wrote:
> Lennart Augustsson wrote:
>
> > To r
Hello,
On Thu, Apr 17, 2008 at 12:05 PM, Martin Sulzmann
<[EMAIL PROTECTED]> wrote:
> Can you pl specify the improvement rules for your interpretation of FDs.
> That would help!
Each functional dependency on a class adds one extra axiom to the
system (aka CHR rule, improvement rule). For the ex
Lennart Augustsson wrote:
To reuse a favorite word, I think that any implementation that
distinguishes 'a -> b, a -> c' from 'a -> b c' is broken. :)
It does not implement FD, but something else. Maybe this something
else is useful, but if one of the forms is strictly more powerful than
the ot
To reuse a favorite word, I think that any implementation that distinguishes
'a -> b, a -> c' from 'a -> b c' is broken. :)
It does not implement FD, but something else. Maybe this something else is
useful, but if one of the forms is strictly more powerful than the other
then I don't see why you w
Iavor Diatchki wrote:
Hello,
On Thu, Apr 17, 2008 at 10:26 AM, Martin Sulzmann
<[EMAIL PROTECTED]> wrote:
leads to an instance improvement/instance improvement conflict,
like in the single-range FD case
class D a b | a -> b
instance D a a => D [a] [a]
instance D [Int] Char
Sorr
Hello,
On Thu, Apr 17, 2008 at 10:26 AM, Martin Sulzmann
<[EMAIL PROTECTED]> wrote:
> leads to an instance improvement/instance improvement conflict,
> like in the single-range FD case
>
> class D a b | a -> b
>
> instance D a a => D [a] [a]
> instance D [Int] Char
Sorry to be picky but ther
Iavor Diatchki wrote:
Hello,
On Wed, Apr 16, 2008 at 11:06 PM, Martin Sulzmann
<[EMAIL PROTECTED]> wrote:
3) Multi-range FDs
Consider
class C a b c | a -> b c
instance C a b b => C [a] [b] [b]
This time it's straightforward.
C [x] y z yields the improvement y = [b] and z = [b]
wh
Hello,
On Wed, Apr 16, 2008 at 11:06 PM, Martin Sulzmann
<[EMAIL PROTECTED]> wrote:
> 3) Multi-range FDs
>
> Consider
>
> class C a b c | a -> b c
>
> instance C a b b => C [a] [b] [b]
>
> This time it's straightforward.
>
> C [x] y z yields the improvement y = [b] and z = [b]
> which then
Sittampalam, Ganesh wrote:
Why not instead transform single-range FDs into multi-range ones where
possible?
That's a perfectly reasonable assumption and would establish the logical
property that
a -> b /\ a -> c iff a -> b /\ c
for FDs (by definition).
> > Why not instead transform single-range FDs into multi-range ones where
> > possible?
> That's a perfectly reasonable assumption and would establish the logical
> property that
> a -> b /\ a -> c iff a -> b /\ c
> for FDs (by definition).
> But what about programmers who'd like that
>
Sittampalam, Ganesh wrote:
Martin Sulzmann wrote:
Mark P Jones wrote:
In fact, the two sets of dependencies that you have given here are
provably equivalent, so it would be decidedly odd to have a "type
improvement" system that distinguishes between them.
Based on the
hackageDB has a substantial sample of code these days, which is handy
for questions like this.
Thanks, Ross. These examples are perfect!
Cheers,
Tom
--
Tom Schrijvers
Department of Computer Science
K.U. Leuven
Celestijnenlaan 200A
B-3001 Heverlee
Belgium
tel: +32 16 327544
e-mail: [EMAIL PR
Martin Sulzmann wrote:
> Mark P Jones wrote:
> > In fact, the two sets of dependencies that you have given here are
> > provably equivalent, so it would be decidedly odd to have a "type
> > improvement" system that distinguishes between them.
> Based on the FD-CHR formulation, for the single-r
Mark P Jones wrote:
Martin Sulzmann wrote:
We're also looking for (practical) examples of "multi-range"
functional dependencies
class C a b c | c -> a b
Notice that there are multiple (two) parameters in the range of the FD.
It's tempting to convert the above to
class C a b c | c -> a, c ->
Martin Sulzmann wrote:
We're also looking for (practical) examples of "multi-range" functional
dependencies
class C a b c | c -> a b
Notice that there are multiple (two) parameters in the range of the FD.
It's tempting to convert the above to
class C a b c | c -> a, c -> b
but this yields a
I think I was the one confused.
I guess I was (falsely) thinking that both
C Int Char T
C Char Int T
could both be instances of class C a b c | c -> a, c -> b but only one
could be an instance of C a b c | c -> a b.
Sorry for adding noise to the discussion.
Ryan Ingram wrote:
I'm sti
I'm still confused about this point:
On 4/16/08, Dan Weston <[EMAIL PROTECTED]> wrote:
> > > class C a b c | c -> a b
> > >
> > > Notice that there are multiple (two) parameters in the range of the FD.
> > >
> > > It's tempting to convert the above to
> > >
> > > class C a b c | c -> a, c -> b
Iavor Diatchki wrote:
Hello,
On Wed, Apr 16, 2008 at 8:06 AM, Martin Sulzmann
<[EMAIL PROTECTED]> wrote:
We're also looking for (practical) examples of "multi-range" functional
dependencies
class C a b c | c -> a b
Notice that there are multiple (two) parameters in the range of the FD.
It
Hello,
On Wed, Apr 16, 2008 at 8:06 AM, Martin Sulzmann
<[EMAIL PROTECTED]> wrote:
> We're also looking for (practical) examples of "multi-range" functional
> dependencies
>
> class C a b c | c -> a b
>
> Notice that there are multiple (two) parameters in the range of the FD.
>
> It's tempting
On Wed, Apr 16, 2008 at 04:30:27PM +0200, Tom Schrijvers wrote:
> I'm looking for practical examples of non-full functional dependencies
> and would be grateful if anyone could show me some or point to
> applications using them.
>
> A non-full functional dependency is one involves only part of th
We're also looking for (practical) examples of "multi-range" functional
dependencies
class C a b c | c -> a b
Notice that there are multiple (two) parameters in the range of the FD.
It's tempting to convert the above to
class C a b c | c -> a, c -> b
but this yields a weaker (in terms of typ
30 matches
Mail list logo