Re: Cat Version 0.15 Release (Mono Bug found)

[Christopher Diggins]

Hi Colin,

Thanks for the bug report,

Could you give me the definition of "unload" that you have? It is
worrisome that you get that as a bug, how could the type inference
engine work different on Mono, I wonder? I really hope this kind of
thing doesn't arrive often. Has anyone else seen this bug?

Also I forgot to include the help-file in the ZIP archive. You can grab it at:
http://cat-language.googlecode.com/svn/trunk/help.txt . Incidentally:
that is the kind of meta-data that I plan on embedding in the
libraries themselves.

- Christopher

On 6/24/07, Colin Hirsch <ma...@cohi.at> wrote:
> colin@tigger:~/Exclude/Download/cdiggins/cat> mono cat_mono.exe
> standard.cat
> failed to load help file
>
> Cat Interpreter
> version 0.15 Sunday, 24 June 2007
> by Christopher Diggins
> this software is released under the MIT license
> the source code is public domain and available at
> http://www.cat-language.com
>
> Type in #help for help and #exit to exit.
>
> type error in function unfold
> inferred type ('S0 't1 ('S0 list 't1 -> 'S0 list 't2 't1) ('S0 list
> 't1 -> 'S0 list 't1 bool) -> 'S0 list)
> declared type ('A 'b ('A list 'b -> 'A list 'c 'b) ('$R305 list 'd ->
> '$R305 list 'd bool) -> 'A list)

[Colin]

Hi,

this test is quickly becoming my classic; here's the result from 0.15
on Mono.

[[pair] [pair] compose] : ('S0 -> 'S0 ('S1 't2 't3 't4 -> 'S1 list))

[[pair] dup compose] : ('S0 -> 'S0 ('S1 't2 't2 't2 't2 list -> 'S1
't2 't2 't2 list))

Regards, Colin

[Christopher Diggins]

That's a great test, thank you very much!

This is an interesting problem. I get a similar problem if I
substitute "42" for "pair".

I'll investigate further,

Cheers,
Christopher

[Christopher Diggins]

Oh, I think I've tracked down the problem. The "dup" operation doesn't
assign new names when a function is duplicated. So: "[42] dup" should
have type
('S0 ('S1 -> 'S1 int) ('S2 -> 'S2 int) but instead it yields "('S0
('S1 -> 'S1 int) ('S1 -> 'S1 int)".

Thanks for your help Colin!

Cheers,
Christopher

[Colin]

Yes, we had already talked about this ... I still have not got further
than to believe that the general solution is to use fresh variables
for all free variables when substituting something for a type
variable ... hopefully we can either prove this assumption, or find
the real solution and really show that it always works.

Regards, Colin

On Jun 29, 9:47 am, "Christopher Diggins" <cdigg...@gmail.com> wrote:
> Oh, I think I've tracked down the problem. The "dup" operation doesn't
> assign new names when a function is duplicated. So: "[42] dup" should
> have type
> ('S0 ('S1 -> 'S1 int) ('S2 -> 'S2 int) but instead it yields "('S0
> ('S1 -> 'S1 int) ('S1 -> 'S1 int)".
>
> Thanks for your help Colin!
>
> Cheers,
> Christopher
>

[Colin]

(Where I'm not even sure what the exact definition of "free variable"
in this context is; first approximation: one that isn't later
substituted during unification, but there's more to it.)

[Christopher Diggins]

On 6/29/07, Colin <goo...@icemx.net> wrote:
>
> (Where I'm not even sure what the exact definition of "free variable"
> in this context is; first approximation: one that isn't later
> substituted during unification, but there's more to it.)
>
> On Jun 29, 2:12 pm, Colin <goo...@icemx.net> wrote:
> > Yes, we had already talked about this ... I still have not got further
> > than to believe that the general solution is to use fresh variables
> > for all free variables when substituting something for a type
> > variable ... hopefully we can either prove this assumption, or find
> > the real solution and really show that it always works.

Yes, I thought this sounded familiar. I think a solution may lie in
removing the "rho" variables until absolutely needed. So we use

[42] : ( -> ( -> int))

instead of

[42] : ('A -> ('B -> 'B int))

I would then only add rho variables during the unification process
where neccessary.

I'll try it out, and let you know how it goes.

Cheers,
Christopher

[Christopher Diggins]

On 6/29/07, Christopher Diggins <cdig...@gmail.com> wrote:

So it turns out that my tweak is effective in tidying up the code, and
inference algorithm. However, the problem still exists.

What you describe is the only solution I can come up with. When
assigning a unifier that is a function to a type variable then any
free variable should be renamed, in case multiple assignments are
made.

This works, but what I have found tricky is identifying what precisely
is a free variables.

Thanks a lot for your help and suggestions Colin, it is much appreciated!

Cheers,
Christopher