home *** CD-ROM | disk | FTP | other *** search
/ Celestin Apprentice 7 / Apprentice-Release7.iso / Source Code / C / Applications / Moscow ML 1.42 / doc / bugs next >
Encoding:
Text File  |  1997-08-18  |  2.1 KB  |  57 lines  |  [TEXT/R*ch]
  1. Known bugs and peculiarities in Moscow ML 1.40 (1 July 1995)
  2.  
  3. * Under MS DOS and MS Windows, timezone information is missing.  Hence
  4. (Date.fmt "%Z" dt) raises an exception under Windows; and returns
  5. nonsense under DOS.  This is a DOS oddity and is unlikely to be fixed.
  6.  
  7. * Under MS DOS, floating point operations use a different precision or
  8. rounding mode than under Linux, so 1.0 / ~1E80 <> ~1E~80 under DOS,
  9. but not under Linux.
  10.  
  11. * Under MS DOS, the FileSys.readDir family of operations sometimes get
  12. confused if other operations are performed on directory dir between
  13. the initial call to FileSys.openDir "dir" and subsequent
  14. FileSys.readDir operations.  Hence one should open, read, and close
  15. the entire directory before performing other file operations on the
  16. same directory.  This is a DOS oddity and is unlikely to be fixed.
  17.  
  18. * The evaluation order in curried function applications is wrong,
  19. leading to wrong results if the applied function may cause side
  20. effects `between the arguments' of the application (reported by
  21. Carsten Mueller, Berlin).  For example, if
  22.  
  23.     exception Right and Wrong
  24.     fun f y = (raise Right; fn x => x)
  25.  
  26. then 
  27.  
  28.     f 7 (raise Wrong); 
  29.  
  30. should raise exception Right, since f is applied to 7 before the
  31. second argument is evaluated, but it raises exception Wrong instead.
  32.  
  33. The bug can be circumvented by splitting the application:
  34.  
  35.     let val f1 = f 7 
  36.     in f1 (raise Wrong) end
  37. or
  38.     let fun g f1 = f1 (raise Wrong)
  39.     in g (f 7) end
  40.  
  41. The problem is that, in Moscow ML, the expression 
  42.  
  43.     f e1 ... en
  44.  
  45. is evaluated by evaluating all argument expressions e1 ... en from
  46. left to right before f is applied to any of them.  Hence if the
  47. function bound to f takes m < n arguments, it gets applied too late.
  48. This causes a problem *only* if evaluation of f causes a side effect,
  49. *and* some of the arguments  e(m+1) ... en  rely on the state or cause
  50. side effects themselves.
  51.  
  52. Since (1) fixing this bug in a straightforward manner would impose a
  53. considerable performance penalty on all curried function applications,
  54. and (2) a programming style exhibiting this bug is pretty rare (it has
  55. not shown up in a real program so far), we have left it in Moscow ML.
  56.  
  57.