f x = x + g
  h y = y:g

It is easy to see that in the first  g  must have the type  num
and in the second  g  must have the type  [*], but all Miranda does
is to issue you with a WARNING that  g  is undefined.  Because of lazy
evaluation it is now possible to evaluate, eg:

  hd (h 2)

and Miranda replies with  2.  I'd prefer a type discipline that does
not allow the above two function definitions to pass through the
type-checker.  Does anyone agree?

But Miranda version 2.009 doesn't accept the above function definitions.
You get an 'UNDEFINED NAME' error for g instead of a warning.
You can't evaluate hd (h 2) then, because h couldn't be defined.
Try to avoid undefined names in older Miranda versions (think ERROR everytime
you see the word WARNING) or use a more recent version.

Andreas

I agree that it would be nice to have this flagged as an error and thus be
prevented from using f or g *but* I don't agree that this is a fault in the
type discipline.

For example, define p and q,

p x = x + g                   q x = x & g
      where                         where
      g = f x                       g = h x

In p both the inferred and actual type of g is num, whilst in q the inferred
type is bool but the actual type is [*].

The type of p is correct because although g is undefined, it is used
consistently throughout the defintion. However, I would like the system to
reject p because it is not completely defined.

|> But Miranda version 2.009 doesn't accept the above function definitions.
|> You get an 'UNDEFINED NAME' error for g instead of a warning.
|> You can't evaluate hd (h 2) then, because h couldn't be defined.

Hmmm.. we have version 2.009 and both definitions get through with only
a warning, and can evaluate hd (h 2). Our system is running on a SUN 3, what
about yours ?

Paul.

"I was dreaming when I wrote this, forgive me if it goes astray"

                       Paul Sanders