Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!tut.cis.ohio-state.edu!ucbvax!hplabs!otter.hpl.hp.com!hpltoad!cdollin!kers
From: kers@hplb.hpl.hp.com (Chris Dollin)
Newsgroups: comp.lang.functional
Subject: Re: Re: Help needed with behaviour of SML (its interactive system)
Message-ID: <KERS.91May10092912@cdollin.hpl.hp.com>
Date: 10 May 91 08:29:12 GMT
References: <9104262016.AA28063@enuxha.eas.asu.edu> <TMB.91Apr26222738@volterra.ai.mit.edu> <20644@ogicse.ogi.edu> <KERS.91May2084808@cdoll
Sender: news@hplb.hpl.hp.com (Usenet News Administrator)
Organization: Hewlett-Packard Laboratories, Bristol, UK.
Lines: 35
In-Reply-To: nico@cs.ruu.nl's message of 6 May 91 14:16:43 GMT
Nntp-Posting-Host: cdollin.hpl.hp.com


Following my message that rubbishes MLs ``incremental'' compilation, a couple
of responses that I want to address ...

Nico Verwer says:

   No, it is very fortunate that ML does NOT have "dynamic scope rules". One
   point has been made before, i.e. type safety.
   But even if the system would enforce some form of type safety ...

It's not dynamic scope (which is to do with rebinding *within new scopes*.
Clearly if the new definition does not ascribe the same type as the old one,
the inconsistency must be resolved some way; for example, the definition could
be disallowed (yuk) or a new variable could be created (and the old one
assigned a value such as "\x. error 'obsolete function called", and maybe all
using functions tagged as obsolete).

Clearly redefining "sin" (Nico's later example) would be a Bad Thing. This just
means that we need some way of annotating those names no longer available for
redefinition - no big deal.

Someone suggested that we needed ``better tools, not worse semantics'', to
solve the problem of rebuilding after a change on which lots of things depend.
Well, I can see the point in that, but it's a matter of opinion as to whether
the semantics is ``worse''; and solving the problem by throwing CPU cycles at
it seems to me to be the wrong approach. First, I'll bet that the time taken
will become appreciable quite quickly; second, those are *my* CPU cycles you're
using; I might want to spend them on something else at the same time (maybe
I've got another system building in the background; perhaps I'm also waiting
for a chess program to deliver it's next move; maybe I have a fancy version of
xfish I'd not like slowed down; etc).
--

Regards, Kers.      | "You're better off  not dreaming of  the things to come;
Caravan:            | Dreams  are always ending  far too soon."