# Type for row based languages

## hallucious — 2009-04-04 21:27:20

    I think that functions on rows can be given types using type constraints - even the weird ones like bi@.

    A type can be given to the composition of functions f g h that is equivalent whether f g or g h are taken first.

    Let f : ( A -> B ) where P

    Let g : ( C -> D ) where Q

    In a type system that does not have ad-hoc polymorphism, then

      f g : ( A -> D ) where P and Q and B = C

    For example:

    bi@ : ( A B (B -> C d) -> E C d d) where A C = E B

    And in a type system that does have it,

     then  f g : ( A -> D ) where P and Q and B < C

    I wrote more details about such a system at

    http://www.nothingontelly.com/RowTypes.txt

    Is there pre-existing work on this?

    Have I made a mistake? Missed something?

    Is there a book I should have read?

## John Nowak — 2009-04-04 22:54:54

    On Apr 4, 2009, at 5:27 PM, hallucious wrote:

     > Is there pre-existing work on this?

     Nothing published that I'm aware of, no. Existing work on type systems

    for concatenative languages (and there isn't much) has mostly focused

    on systems with decidable type inference.

     > Have I made a mistake? Missed something?

     Not that i can see. Do you have any application in mind for it?

    I suppose my only comment is that I'm not sure if your approach is

    ideal for concatenative languages. In my personal experience,

    intersection types seem to be a much better match. For example, the

    type of 'dup apply' in a system with intersection types can be stated

    rather simply:

         A (b /\ (A b -> C)) -> C

    If you assume 'dup' to have the type 'A (b /\ c) -> A b c', inference

    is straightforward:

         A (b /\ c) -> A b c

                       D   (D -> E) -> E

         A (b /\ (D -> E)) -> A b (D -> E)

                              D   (D -> E) -> E

         A (b /\ (A b -> E)) -> A b (D -> E)

                                A b (D -> E) -> E

         A (b /\ (A b -> E)) -> E

    As for your '[id] dup' example:

         A -> A (B -> B)

              C (d /\ e) -> C d e

         -- B free in B -> B, make fresh

         A -> A ((B -> B) , (F -> F))

              C (d        , e       ) -> C d e

         A -> A ((B -> B) , (F -> F))

              C ((B -> B) , e       ) -> C (B -> B) e

         A -> A ((B -> B) , (F -> F))

              C ((B -> B) , (F -> F)) -> C (B -> B) (F -> F)

         A -> A ((B -> B) , (F -> F))

              A ((B -> B) , (F -> F)) -> A (B -> B) (F -> F)

         A -> A (B -> B) (F -> F)

    Apologies for not having anything more constructive for your system in

    particular.

    - John

## John Nowak — 2009-04-04 23:08:32

    One more thing I should've mentioned. You state that your type system

    is compositional. I should note that you can get this quite easy by

    extending HM with row types and omitting any equivalent to let

    polymorphism. For example, 'dup apply' would fail to type:

         A b -> A b b

                C   (C -> D) -> D

         A (C -> D) -> A (C -> D) (C -> D)

                       C          (C -> D) -> D

         -- error: C occurs in A (C -> D)

    Luckily (for some definition of "luck"), something like '[id] dup

    apply' would fail as well:

         A -> A (B -> B)

              C d        -> C d d

         A -> A (B -> B)

              C (B -> B) -> C (B -> B) (B -> B)

         A -> A (B -> B)

              A (B -> B) -> A (B -> B) (B -> B)

         A -> A (B -> B) (B -> B)

         A -> A (B -> B) (B -> B)

              C          (C -> D) -> D

         A -> A (D -> D) (D -> D)

              C          (C -> D) -> D

         A -> A (C -> C) (C -> C)

              C          (C -> C) -> C

         -- error: C occurs in A (C -> C)

    For all expressions that do yield valid types, the order in which you

    infer the type does not matter.

    Apologies if I'm stating the obvious.

    - John

## hallucious — 2009-04-05 01:14:17

    One motivation for this work was to broaden the range of functions

    which can be investigated by looking at their type, which can be

    useful to see their effect. Another was to allow the programmer to

    provide additional constraints. I also hoped that the type would form

    a basis for proving properties of any function, using denotation

    provided by the programmer. I did not want the type system to restrict

    which functions or algorithms could be considered. We should be free

    to get a function working empirically, then prove its correctness.

    And another was to use inheritance polymorphism, mix in native objects

    from Java or C# and type their interfaces, and investigate uniqueness

    types in concatenative languages. Perhaps an undecidable type system

    is not really necessary for this. But I wanted a type system for

    experimental programs that might be rejected by conventional type

    systems.

    I do not expect that there is any automated (unguided) procedure to

    check, for instance, whether two type formulas are equivalent in this

    system. Is this what decidable type inference means?

## hallucious — 2009-04-05 01:41:42

    If decidable type inference means that the type of quotations and compositions of functions can be inferred and expressed, then I think that type inference is decidable in this system. You are not forced to simplify. (I should have pointed that out.)

    But I do not think that type checking or type equality are decidable.

## John Nowak — 2009-04-05 06:27:11

    On Apr 4, 2009, at 9:41 PM, hallucious wrote:

     > If decidable type inference means that the type of quotations and

    > compositions of functions can be inferred and expressed, then I

    > think that type inference is decidable in this system. You are not

    > forced to simplify. (I should have pointed that out.)

     It's easy to infer the constraints, but type inference (I believe)

    also entails checking that those constraints are satisfied and not in

    contradiction to one another. For example, you may have the following

    composition:

         A b -> A b      b Int

                C String d d   -> E

    And you could assign it the following type:

         A b -> E where A < C and b = String and b < d and d = Int

    This alone is not useful because the type inferred is not valid.

    - John

## hallucious — 2009-04-05 09:09:21

    Hi John,

    Thanks for the info and for bearing with me.

    I do want to move on to type systems that are useful for compilers.

    I shall clarify the subordinate role of this type system in the report.

    Adrian

## John Nowak — 2009-04-06 12:00:38

    On Apr 5, 2009, at 5:09 AM, hallucious wrote:

     > Thanks for the info and for bearing with me.

    > I do want to move on to type systems that are useful for compilers.

     It seems to me that some of the most interesting work in this field

    (type systems for compilers) is being done by the Church Project (http://www.church-project.org

    ). They've already done much work on compositional analysis which may

    be useful to you if you're not already familiar with it.

    - John