home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / lang / pop / 218 < prev    next >
Encoding:
Internet Message Format  |  1993-01-25  |  3.0 KB
  1. Path: sparky!uunet!noc.near.net!nic.umass.edu!dime!roo.cs.umass.edu!pop
  2. From: pop@cs.umass.edu ( Robin Popplestone )
  3. Newsgroups: comp.lang.pop
  4. Subject: dlocals
  5. Message-ID: <59101@dime.cs.umass.edu>
  6. Date: 25 Jan 93 18:08:52 GMT
  7. Sender: news@dime.cs.umass.edu
  8. Organization: University of Massachusetts, Amherst
  9. Lines: 52
  10. Originator: pop@roo.cs.umass.edu
  11.  
  12. > But of course, you have to keep changing the definition of the
  13. > structure Env for different purposes, which can makes reuse of code
  14. > difficult.
  15.  
  16.  
  17. This of course is missing the point of functional abstraction - POP in some
  18. sense has no data-structures, only functions. So you can just extend
  19. environments by introducing new selector functions. The trouble with this
  20. approach is of course the *constructor functions* which have an arity that
  21. is specific to a particular application.
  22.  
  23. A useful approach to dealing with this problem is to introduce constructive
  24. ways of changing individual components of a data-structure (I usually call
  25. them with_X - eg  L with_hd 2  is the list L with its head constructively
  26. replaced by 2). I think that something similar is talked of for ML.
  27.  
  28. Alternatively, you can make environments be properties which map names to
  29. values.
  30.  
  31. >Also when the environment changes you either have to use
  32. > dlocal anyway, to ensure that it is automatically reset whenever
  33. > procedure exit occurs, or else you have to copy the structure on
  34. > entry to any procedure that can change it.
  35.  
  36. Well...there is profit for many applications in using POP as a
  37. functional-language-toolkit, in a style in which you write you topmost
  38. layer (the user interface) and your bottom layer (*your* primitive
  39. functions) in a non-functional way, but write the rest in a pure functional
  40. form. This means in particular that you obtain log times for
  41. the incremental computations of tree-to-tree functions via memoisation.
  42. All problems of algebraic simplification and compilation are much eased by
  43. such an approach (algebraic simplification is usually conducted in some
  44. kind of environment - e.g. what order to sort the variables, whether to
  45. apply distributivity, trig. identities...). In particular, one would be
  46. able to perform log time incremental compilation of context-sensitive
  47. languages like ADA, instead of the linear time compilation characteristic
  48. of conventional compilers. (...for changes that didn't involve a change to
  49. a global declaration that is...).
  50.  
  51. Generally, I think the world made a big mistake when it went for the likes
  52. of C as a systems language, and regarded a system like Multipop as the
  53. muddling along of amateurs. I believe that decent functional abstraction
  54. could (e.g.) provide flavours of X that are efficiently local or
  55. distributed as required by an application, and that the uniform checking
  56. mechanisms of POP avoid inefficiencies arising from non-uniform checking
  57. mechanisms that C programmers are forced to hack up. But some of the things
  58. you can get with NJML (and that they are actively exploiting in CMU) do
  59. require that variables be lexical.
  60.  
  61.  
  62.  
  63. Robin
  64.