Type Order

Christopher Diggins — 2006-12-07 20:21:45

I have had another comment that the order of types expressed in Cat is

somewhat unintuitive. For example:



define f : ()->(char int) { 42 'q' }



I was wondering if anyone else has an opinion on the subject?



Christopher Diggins

http://www.cdiggins.com

William Tanksley, Jr — 2006-12-09 00:44:46

Christopher Diggins <cdiggins@...> wrote:

 > I have had another comment that the order of types expressed in Cat is

> somewhat unintuitive. For example:

> define f : ()->(char int) { 42 'q' }

> I was wondering if anyone else has an opinion on the subject?



 
I know why the other way is usually used: because the types can be

lexically replaced with examples of the types to produce a correct

result. In other words,  '(char int)' can be satisfied by 'q' 42.



Why is your way used?



 > Christopher Diggins



 
-Billy

Christopher Diggins — 2006-12-09 18:53:08

On 12/8/06, William Tanksley, Jr <wtanksleyjr@...> wrote:

 > Christopher Diggins <cdiggins@...> wrote:

> > I have had another comment that the order of types expressed in Cat is

> > somewhat unintuitive. For example:

> > define f : ()->(char int) { 42 'q' }

> > I was wondering if anyone else has an opinion on the subject?

>

> I know why the other way is usually used: because the types can be

> lexically replaced with examples of the types to produce a correct

> result. In other words, '(char int)' can be satisfied by 'q' 42.



 
Thanks for your feedback!



 > Why is your way used?



 
There were two primary reasons

1) if one views a stack as an infinite list, it is customary to write

infinite lists so that the right side is an ellipsis representing the

rest of the list. IOW the following is uncommon ...



(..., a1, a0)



2) The other reason is that type variables would have to be declared

before they are used, so they would appear on the right.



eval : (A (A:any* -> B:any*) -> B)



So I am pretty much convinced that my approach isn't sufficiently

justified to warrant breaking so far from intuition and convention.



Cheers,

Christopher

William Tanksley, Jr — 2006-12-16 03:26:00

Christopher Diggins <cdiggins@...> wrote:

 > Thanks for your feedback!



 
You can usually count on me to open my mouth ;-). I haven't read your

paper yet -- I just got back from vacation.



 > > Why is your way used?



> There were two primary reasons

> 1) if one views a stack as an infinite list, it is customary to write

> infinite lists so that the right side is an ellipsis representing the

> rest of the list. IOW the following is uncommon ...

> (..., a1, a0)



 
Now that makes a lot of sense. The stack effect is definitely an

indefinite list.



 > 2) The other reason is that type variables would have to be declared

> before they are used, so they would appear on the right.

> eval : (A (A:any* -> B:any*) -> B)



 
Another solution to this would be to allow the user to provide the

type restriction anywhere, and require the type inferencer to figure

it out. If your parser is simple and linear that's not possible, but I

doubt it is, because the problem you've solved (type inference) isn't

simple or linear.



 > So I am pretty much convinced that my approach isn't sufficiently

> justified to warrant breaking so far from intuition and convention.



 
Well, you know my opinion :-).



 > Christopher



 
-Billy