wald-david@CS.YALE.EDU (david wald) (02/17/89)
In article <2008@goofy.megatest.UUCP> djones@megatest.UUCP (Dave Jones) writes: >From article <1398@quanta.eng.ohio-state.edu>, by rob@kaa.eng.ohio-state.edu (Rob Carriere): >> What seems to be missing is the idea that sleep *does* modify >> something, namely time. So formally speaking, your compiler should >> consider sleep to have a side effect on a variable called __time. If >> you do that, there's no problem. > >Huh?? > >On a time-shared system (such as Unix), does every instruction have >a side effect on a variable called __time? Point taken, but we still need a way to describe the difficulty with treating sleep() as a pure function. The actual difficulty is related to the problem with volatile variables. The compiler can't optimize sleep() calls away, since they rely on some external (volatile) clock variable (or some system call accessing this variable) for their behavior. ============================================================================ David Wald wald-david@yale.UUCP waldave@yalevm.bitnet wald-david@cs.yale.edu "A monk, a clone and a ferengi decide to go bowling together..." ============================================================================
dik@cwi.nl (Dik T. Winter) (02/17/89)
In article <50915@yale-celray.yale.UUCP> wald-david@CS.YALE.EDU (david wald) writes: > Point taken, but we still need a way to describe the difficulty with > treating sleep() as a pure function. No problem, it performs a system call. (And if you code sleep as a loop without system call the compiler will be able to optimize it away.) -- dik t. winter, cwi, amsterdam, nederland INTERNET : dik@cwi.nl BITNET/EARN: dik@mcvax
henry@utzoo.uucp (Henry Spencer) (02/18/89)
In article <50915@yale-celray.yale.UUCP> wald-david@CS.YALE.EDU (david wald) writes: >... we still need a way to describe the difficulty with >treating sleep() as a pure function... This seems trivial: sleep() invokes at least one system call, which in turn is not a pure function. If you take a purist viewpoint, this doesn't help, because one then has to figure out how to tell the compiler that the system call is not a pure function. If you take a pragmatic viewpoint, however, there *has* to be a way to say such things anyway, because it's grossly unrealistic to assume that compiled code will never need to talk to "black box" library functions whose innards are not known to the compiler. There has to be a way to specify just the external behavior, e.g. pureness or non-pureness. -- The Earth is our mother; | Henry Spencer at U of Toronto Zoology our nine months are up. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu