Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!mips!spool.mu.edu!news.nd.edu!mentor.cc.purdue.edu!purdue!haven!ni.umd.edu!uc780.umd.edu!cs450a03
From: cs450a03@uc780.umd.edu
Newsgroups: comp.lang.misc
Subject: RE: Dynamic typing (part 3)
Message-ID: <17APR91.21405707@uc780.umd.edu>
Date: 17 Apr 91 21:40:57 GMT
References: <1593@optima.cs.arizona.edu> <28959@dime.cs.umass.edu> <8APR91.20240323@uc780.umd.edu> <29037@dime.cs.umass.edu>
Sender: usenet@ni.umd.edu (USENET News System)
Organization: The University of Maryland University College
Lines: 46

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