🚀 go-pugleaf

Victor Yodaiken    >
Me                 >>

>B: Type declarations do not necessarily only have to do with how data
>is stored. A type declaration: "z in Domain(g) is a number" or "z in
>Range x is a binary tree" or "Domain of f is ordered under >" all
>seem like useful type declarations, but they have nothing to do with
>storage.

Ok, let's take "z in Domain(g) is a number" as an example.  What is
the result of that statement?

If you're dealing with static typing, then I suppose you would say
that the compiler dutifully takes note of the statement and rejects
usages of z which conflict with this declaration.  But what if
computing Domain(g) is a problem?  Let's say z is an offset into a
file.  If you want this to be statically typed, you've just specified
a fixed-sized file.

>>Let me pose a "classic typing problem":
>>F(x) and f(x) are defined for some domain D -> D, but are not one-to-one
>>G(x) is an inverse to F(x) for some values in D
>>g(x) is an inverse to f(x) for some values in D
>>F, f, G and g are all implemented as user defined functions on some
>>computer system.  All are pure computation (no side-effects).
>>What type must x be for G(g(x)) to be meaningful?
>>
>>An easy way to deal with this problem is issue "message not
>>understood" where x is invalid.  Note that significant computation (g)
>>may occur before this situation is recognized.
>>
>>Sometimes it may be recognized that if x is limited to some sub-domain
>>d, then G(g(x)) will always be meaningful.  Sometimes the computer
>>might recognize this, sometimes the programmer might.  Sometimes the
>>problem is too hard.

>I don't believe that there is a good reason for writing programs with
>non-deterministic behavior

There is nothing non-deterministic in that problem.  For example,
let's say that G(y) is 1/p(y) where p(y) is 0 when y is a positive
integer.  Let's say g(x) always gives results which are less than 0 --
pretty easy to deal with, eh?  But what if g(x) can give results which
are positive integers?

Raul Rockwell