Thanks,
Perhaps my algorithm works then. I shall have to read up more on these
things :)
- Job
On Mon, Feb 21, 2011 at 4:54 PM, Luke Palmer wrote:
> On Sun, Feb 20, 2011 at 6:01 PM, Job Vranish wrote:
> > My current algorithm says that neither of the types you gave is strictly
> > more general
On Sun, Feb 20, 2011 at 6:01 PM, Job Vranish wrote:
> My current algorithm says that neither of the types you gave is strictly
> more general than the other, which I'm guessing is probably not true. I'm
> curious what the correct answer is and would appreciate someone pointing out
> the flaw in my
>From: Job Vranish
>On Sun, Feb 20, 2011 at 8:56 PM, Brandon Moore
>wrote:
>>Typechecking with regular types isn't hard.
> So do I have the right idea then? To check against a signature, I can just
>unify
>
> the two types and then check if the unified type is 'equivalent' (is there a
> spec
On Sun, Feb 20, 2011 at 8:56 PM, Brandon Moore wrote:
>
>
> Typechecking with regular types isn't hard.
So do I have the right idea then? To check against a signature, I can just
unify the two types and then check if the unified type is 'equivalent' (is
there a special word for this kind of equiv
>From: Job Vranish
>
>Sorry for bringing back an ancient thread but I'd still like to understand
>this
>better.
>
>It is still not obvious to me why typechecking infinite types is so hard. Is
>determining type 'equivalence' the hard part? or is that a separate issue?
Typechecking with regular
Sorry for bringing back an ancient thread but I'd still like to understand
this better.
It is still not obvious to me why typechecking infinite types is so hard. Is
determining type 'equivalence' the hard part? or is that a separate issue?
I wrote a simple infinite type inferer and made an attem
On Sat, Feb 14, 2009 at 2:06 PM, Job Vranish wrote:
> I'm pretty sure that the problem is decidable, at least with haskell
> 98 types (other type extensions may complicate things a bit). It ends
> up being a graph unification algorithm. I've tried some simple
> algorithms and they seem to work.
>
I'm pretty sure that the problem is decidable, at least with haskell
98 types (other type extensions may complicate things a bit). It ends
up being a graph unification algorithm. I've tried some simple
algorithms and they seem to work.
What do you mean by "the inference engine is only half of the
On Fri, Feb 13, 2009 at 4:04 PM, Luke Palmer wrote:
> On Fri, Feb 13, 2009 at 3:13 PM, Job Vranish wrote:
>
>> There are good reasons against allowing infinite types by default
>> (mostly, that a lot of things type check that are normally not what we
>> want). An old haskell cafe conversation on
On Fri, Feb 13, 2009 at 3:13 PM, Job Vranish wrote:
> There are good reasons against allowing infinite types by default
> (mostly, that a lot of things type check that are normally not what we
> want). An old haskell cafe conversation on the topic is here:
>
> http://www.nabble.com/There%27s-noth
There are good reasons against allowing infinite types by default
(mostly, that a lot of things type check that are normally not what we
want). An old haskell cafe conversation on the topic is here:
http://www.nabble.com/There%27s-nothing-wrong-with-infinite-types!-td7713737.html
However, I think
11 matches
Mail list logo
