# While we're not moved

## sz — 2000-09-01 14:23:40

    Hello Concatenative,

    I thought on static typechecker for Joy.

    Let us adapt Haskell notation where types (and constructors) are names

    that start from upper case letter and variables are names that start

    from lower case letters.

    Then it is easy to define type patterns for some kinds of operators:

    dup ( x -- x x)

    +   ( x x -- x) because we can add integers and floats (and chars)

    eq0 ( x -- Bool) also we may take float, char and integer.

    1   ( -- Int)

    1.0 ( -- Float)

    '1  -- gues what type has '1 ;)

    Then I tried to infer type for +1:

    +1 == 1 + ;

    + has type ( x x -- x) where one of x is set by literal 1 to Int. Then

    all x's set to Int. And one x come from input stack. Then type of +1

    is ( Int -- Int). Very straightforward and simple.

    If we use type pattern to distinguish between different primitives

    with the same name (as in StrongForth) then it is possible to develop

    version of +1 for floats and characters.

    But when I thought about use of lists I come into interesting problem.

    What to expect when taking apart head and tail from list?

    For example, one of my thoughts about lists is to use syntax like

    splitlist ( [x *tail] -- [*tail] x)

    Consequently,

    concat    ( x [*l]    -- [x *l])

    where * means that we have no knowledge about remaining number of

    elements in list.

    putstr definition should have type ( [*Char] --)

    It was not a problem. Problem (or a task or a food for thought) is the

    following: we construct some list using some grammar hidden inside Joy

    definitions and static typechecker should know about that grammar (or

    more precisely -- reversed grammar) to know what to expect when taking

    list apart.

    How, for example, not to put empty list as splitlist argument? Guard

    it with checking for emptyness? Then how to (automatically) strip

    that check?

    Best regards,

     sz                          mailto:sz@...