# 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