home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / lang / lisp / 3409 < prev    next >
Encoding:
Text File  |  1993-01-28  |  2.1 KB  |  57 lines
  1. Newsgroups: comp.lang.lisp
  2. Path: sparky!uunet!widget!pole
  3. From: pole@evb.com (Tom Pole)
  4. Subject: Re: Lisp syntax beauty? (was Re: Why Isn't Lisp a Mainstream Language?)
  5. Message-ID: <1993Jan28.190225.9215@evb.com>
  6. Organization: EVB Software Engineering, Inc.
  7. References: <19930122162651.0.SWM@SUMMER.SCRC.Symbolics.COM> <dfs.727723285@noonian> <C1GEsq.94@stl.dk>
  8. Date: Thu, 28 Jan 1993 19:02:25 GMT
  9. Lines: 46
  10.  
  11. In article <C1GEsq.94@stl.dk> flv@stl.dk (Flemming Vestergaard) writes:
  12. >In <dfs.727723285@noonian> dfs@doe.carleton.ca (David F. Skoll) writes:
  13. >
  14. >>I've noticed a thread extolling the beauty of Lisp syntax.  While I agree
  15. >>that mostly, Lisp syntax is easy to understand and consistent, I wonder
  16. >>what sort of mental disease struck the creators for the "format" function.
  17. >>Take a look at all the baroque format directives in Common Lisp.  I mean,
  18. >>who really needs the number 394829348234982435 formatted in English words??
  19. >>Just try (format t "~R~%" 394829348234982435) for fun!
  20. >
  21. >Well, it is fun. But from this corner of the world I suppose that it is
  22. >a more serious problem (if not a disaster) that Common Lisp provides 
  23. >input and output functions that are suited only for English/American.
  24. >
  25. >(format t "~R" 4) -> four really doesn't help very much in most of the world.
  26.  
  27.  
  28. I'm a bit confused. The fact that the output is in 'American' is somehow
  29. different from the code being in 'American'. Don't 'C', Fortran, Basic, Ada
  30. compilers' source code in all countries use "print", "open", "type", 
  31. "character", "in", "out", etc., etc. This may be a complaint, but surely 
  32. not a complaint about Lisp syntax/semantics. 
  33.  
  34. I don't believe it would be terribly difficult to write a lisp extention
  35. to allow a format method to be defined on a foreign language object
  36. to produce the textual versions of numbers. I believe that Lisp
  37. syntax/semantics and its dynamic/extensible nature would also make
  38. such an extention easier to implement in Lisp than in most other 
  39. languages.
  40.  
  41. >And yes-or-no-p cannot be used either.
  42.  
  43.     Thomas
  44.  
  45. >
  46. >I do think it is a mistake to include natural language specific functions
  47. >in a language standard.
  48.  
  49.  
  50. >
  51. >Flemming
  52.  
  53.  
  54. -- 
  55.  
  56. Thomas Pole
  57.