home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / edu / 1660 < prev    next >
Encoding:
Internet Message Format  |  1992-09-14  |  3.1 KB
  1. Xref: sparky comp.edu:1660 comp.lang.fortran:3556 comp.lang.misc:3076 comp.arch:9421 sci.math:11467
  2. Newsgroups: comp.edu,comp.lang.fortran,comp.lang.misc,comp.arch,sci.math
  3. Path: sparky!uunet!munnari.oz.au!cs.mu.OZ.AU!munta.cs.mu.OZ.AU!fjh
  4. From: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON)
  5. Subject: Re: User-Defined Operators (was: Scientists as Programmers (was: Small Language Wanted))
  6. Message-ID: <9225915.145@mulga.cs.mu.OZ.AU>
  7. Sender: news@cs.mu.OZ.AU
  8. Organization: Computer Science, University of Melbourne, Australia
  9. References: <1992Sep13.022830.2046@CS.ORST.EDU> <1992Sep14.090213.18722@uklirb.informatik.uni-kl.de> <mcdonald.299@aries.scs.uiuc.edu>
  10. Distribution: na
  11. Date: Tue, 15 Sep 1992 05:42:27 GMT
  12. Lines: 53
  13.  
  14. mcdonald@aries.scs.uiuc.edu (J. D. McDonald) writes:
  15.  
  16. >kirchner@uklira.informatik.uni-kl.de (Reinhard Kirchner) writes:
  17. >
  18. >>If one wants to see and USE a language with user definable operators:
  19. >
  20. >>Take Pascal-XSC. It is available on all unix machines since it compiles to
  21. >>standard C. It allows users to define operators monadic and dyadic, and it
  22. >>comes with many of them for interval, vector, matrix, complex etc.
  23. >>computations.
  24. >
  25. >However, the results will be no faster .... and almost surely slower,
  26. >than simply coding in C.
  27.  
  28. Why "almost surely slower" than C?
  29. Mr. Kirchner says that the language compiles to standard C;
  30. I do not see any reason why the C code produced would be likely to be
  31. worse than writing it in C in the first place.
  32.  
  33. >What you are describing is **NOT** user definable operators in the sense that
  34. >they are **needed**!! What is needed is the ability to define operators
  35. >that map one-to-one to the exact machine operations that are present,
  36. >to give the fastest possible results.
  37.  
  38. gcc offers exactly this capability (see the documentation regarding
  39. "Extended Asm").
  40. It does not allow the user to introduce arbitrary new operators; however
  41. it appears likely that using the combination of Pascal-XSC and gcc you
  42. could achieve what you are after.
  43.  
  44. >What you describe adds no new capabilities to the language. You would
  45. >still need assembler to access the full capabilities of the machine.
  46. >Remember that **NO** langauage can ever add capabilities to assembler,
  47. >because assembler can do anything. HLLs  can only prevent use of 
  48. >things assembler can do.
  49.  
  50. What about the "capability" to write portable code?
  51. What about the "capability" to write <application XYZ> in less
  52. than N lines of code? In less than M hours of programming time?
  53. For a cost of less than D dollars?
  54. What about the "capability" to write complex programs that even first year
  55. students can understand?
  56.  
  57. If you are arguing that HLLs are not useful, then you are obviously wrong.
  58. If you are trying to point out that assembler is Turing-complete, then so what?
  59. In rare situations, it is necessary to use assembler. But for the great
  60. majority of cases, it is far more cost-effective to use a HLL.
  61.  
  62. -- 
  63. Fergus Henderson             fjh@munta.cs.mu.OZ.AU      
  64. This .signature virus is a self-referential statement that is true - but 
  65. you will only be able to consistently believe it if you copy it to your own
  66. .signature file!
  67.