home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / arch / 10872 < prev    next >
Encoding:
Internet Message Format  |  1992-11-15  |  2.2 KB
  1. Xref: sparky comp.arch:10872 comp.lang.misc:3761
  2. Path: sparky!uunet!kithrup!stanford.edu!agate!biosci!uwm.edu!zaphod.mps.ohio-state.edu!rpi!psinntp!psinntp!dg-rtp!sheol!throopw
  3. From: throopw@sheol.UUCP (Wayne Throop)
  4. Newsgroups: comp.arch,comp.lang.misc
  5. Subject: adding new operators on the fly
  6. Message-ID: <722061125@sheol.UUCP>
  7. Date: 18 Nov 92 01:44:01 GMT
  8. References: <1992Nov13.155126.3660@linus.mitre.org>
  9. Lines: 38
  10.  
  11. : From: bs@gauss.mitre.org (Robert D. Silverman)
  12. : Message-ID: <1992Nov13.155126.3660@linus.mitre.org> 
  13. : I would like to see a language that has a feature that will allow
  14. : me to (say) define new operators that use specific machine instructions.
  15. : for example: (pseudocode)
  16. :
  17. :       define binary operator arg1 ** arg2  as  'emul arg1 arg2'
  18.  
  19. This doesn't even begin to address all the necessary aspects of
  20. defining a new operator.  What prescedence does "**" have?  What are
  21. restrictions the compiler must know about which registers arg1 and arg2
  22. must be loaded into?  What should the compiler do if there's a type
  23. mismatch in the arguments (eg: you try to do this to floating point
  24. numbers).  And so on and on and on.
  25.  
  26. These (among other reasons) are why gcc encourages access to assembly
  27. instructions with functional notation.  You can at least specify input
  28. and output types, and you don't have to worry about operator
  29. prescedence issues, or lexical or syntactic ambiguity after the
  30. introduction of the new operator.
  31.  
  32. There *are* languages that allow introduction of operators, but they
  33. sidestep a lot of the issues by not defining the operators in terms of
  34. machine instructions, but of other language constructs, and sidestep
  35. others by including notation for type compatibility and operator
  36. prescedence, and so on and on.
  37.  
  38. Code generation just isn't as simple as associating a concrete instruction
  39. with an abstract operation, and syntactic recognition isn't as simple as
  40. spelling all the operators.  The above notation doesn't even *begin*
  41. to be adequate to the task it is allegedly intended for.
  42.  
  43.  
  44. ( Now granted: the example was "pseudocode".  But nevertheless, the
  45.   example gives no clue how this pseudocode can even potentially be
  46.   elaborated into a practical notation. )
  47. --
  48. Wayne Throop  ...!mcnc!dg-rtp!sheol!throopw
  49.