home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / object / 3249 < prev    next >
Encoding:
Text File  |  1992-08-18  |  5.2 KB  |  123 lines

  1. Newsgroups: comp.object
  2. Path: sparky!uunet!europa.asd.contel.com!darwin.sura.net!Sirius.dfn.de!chx400!bernina!neptune!santas
  3. From: santas@inf.ethz.ch (Philip Santas)
  4. Subject: Re: O.M() versus M(O) notation
  5. Message-ID: <1992Aug18.215440.16673@neptune.inf.ethz.ch>
  6. Sender: news@neptune.inf.ethz.ch (Mr News)
  7. Nntp-Posting-Host: spica.inf.ethz.ch
  8. Organization: Dept. Informatik, Swiss Federal Institute of Technology (ETH), Zurich, CH
  9. References: <PCG.92Aug16184526@aberdb.aber.ac.uk> <1992Aug17.222621.1099@neptune.inf.ethz.ch> <PCG.92Aug18145434@aberdb.aber.ac.uk>
  10. Date: Tue, 18 Aug 1992 21:54:40 GMT
  11. Lines: 110
  12.  
  13.  
  14. In article <PCG.92Aug18145434@aberdb.aber.ac.uk> pcg@aber.ac.uk (Piercarlo Grandi) writes:
  15. >On 17 Aug 92 22:26:21 GMT, santas@inf.ethz.ch (Philip Santas) said:
  16. >
  17. >santas> you seem to argue that functions receive more than one
  18. >santas> arguments.
  19. >
  20. >Ah no, ah no. I have not committed myself on this! (even if a lot of
  21. >people would like to commit me! :->). Here I would make the point that
  22. >there is some difference between 'function' and 'procedure'. In the case
  23. >of 'function' there is some disagreement, dutifully reflected in the
  24. >syntax of ML 'procedures' for example, as to whether a function over two
  25. >domains is really:
  26.  
  27. Can we please avoid using ''s to already hopelessly oveloaded names?
  28.  
  29. >       a function over a cartesian product
  30. >       a functional over a function over one domain
  31. >in other words, using a Lisp-like notation, whether (plus x y) is really:
  32. >       (apply sum-of (list x y))
  33. >       (apply (incr-by x) y)
  34.  
  35. I'm not sure if the later really does you want: it will return just 'y,
  36. right? In my opinion you do not need to use 'apply in this case.
  37. The correct is: ((incr-by x) y).
  38.  
  39. >santas> Well, all my functions receive one argument, and I think that
  40. >santas> most CS scientists and mathematicians agree with this.
  41. >
  42. >Uhmm. But I was speaking of notation/syntax/interface. And the notation
  43. >I was commenting about does have multiple arguments. Your observation
  44. >applies to functions or maybe to procedures, not to their interfaces.
  45. >Their interfarces are just syntax, notation used to access such
  46. >procedures or their underlying functions. As such the notation used is
  47. >not terribly important, as long as it is clear, convenient, and proper.
  48.  
  49. I think that here things are getting mixed up.
  50. I really find pontless to start a discussion of what is syntax and what
  51. semantics, when the one derives to the second at different levels
  52. of abstraction. Said this, it is clear that
  53.  "the syntax should give a clear idea of what is intended to happen"
  54. This is why you missed the following three different cases.
  55.  
  56. >santas> I propose you to consider (and comment) the following three
  57. >santas> cases: M (O,...) [ ... ] (O,...) M [ ... ] O M (...)
  58. >
  59. >This I have already done :-). Prefix, postfix, infix notation:
  60.  
  61. It is not so superficial as you try to show. I use all these cases
  62. with the same syntax.
  63.  
  64. The first case is a function M with argument the tuple (O,...)
  65.                      (or):   M which receives the tuple (O,...),
  66. where we have a function M with a certain type.
  67.  
  68. In the second case we have (O,...) receiving M. It is not only superficial
  69. change, we have the _type_ of the _tuple_ and we have added M to its 
  70. specification.
  71.  
  72. In the third case we have O receiving M, producing an instance (function, 
  73. object, depending to one's tastes) which operates on the tuple (...)
  74. Here M belongs to the specification of O's type.
  75.  
  76. As one can see why have different type specifications involved.
  77. If a tricky compiler can decide which one is better implemented,
  78. it may choose to optimise the whole thing into something which
  79. has nothing to do with functions or classes, but this does not change
  80. the user's intentions, and the different methods implied by the 
  81. three cases.
  82.  
  83. >Frankly what I really care about is not the notation itself, but the
  84. >fact that the overload resolution agent (aka binder, dispatcher,
  85. >messager, etc.) is given an N-uple
  86. >       (O,M,A,B,C,...)
  87. >which may or may not be ordered (even if usually the A,B,C,... are
  88. >positional and thus ordered), and from this it has to find a compatible
  89. >implementation/body/etc. to apply. 
  90.  
  91. "usually" is very sloppy here. If M is commutative then and only then
  92. you can say that order is not important. Notice that in the 2nd and 3rd 
  93. case the order of execution is already defined and this makes them different
  94. than the first..
  95.  
  96. >I quite like the prefix lisp notation
  97. >       (M O A B C ...)
  98. >that more clearly reflects this, and is in some way just a shorthand fo
  99. >       (apply (resolve M O A B C ...) A B C ...)
  100. >And indeed that is the way the Lisp systems reads it.
  101.  
  102. As you have seen the problem is more than notation.
  103. How do you resolve the case (O A M B C D ...) ?
  104. when more than one of these arguments are functions?
  105.  
  106. It seems to me that you do not follow your _own_ definitions.
  107. (or I may have missunderstood them :-)
  108.  
  109. Philip Santas
  110.  
  111.   "In an evolving universe those who stand still are really moving backwards"
  112. --------------------------------------------------------------------------------
  113. email: santas@inf.ethz.ch                 Philip Santas
  114. Mail: Dept. Informatik                Department of Computer Science
  115.       ETH-Zentrum              Swiss Federal Institute of Technology
  116.       CH-8092 Zurich                       Zurich, Switzerland
  117.       Switzerland
  118. Phone: +41-1-2547391
  119.      
  120.  
  121.  
  122.  
  123.