home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / lang / tcl / 2222 < prev    next >
Encoding:
Text File  |  1992-12-22  |  3.8 KB  |  93 lines
  1. Newsgroups: comp.lang.tcl
  2. Path: sparky!uunet!haven.umd.edu!darwin.sura.net!zaphod.mps.ohio-state.edu!magnus.acs.ohio-state.edu!bgsuvax!att!cbnewsm!gah
  3. From: gah@att.com (George A. Howlett)
  4. Subject: Re: Advice wanted on math functions for Tcl 7.0
  5. Reply-To: george.howlett@att.com
  6. Organization: AT&T Bell Laboratories
  7. Date: Tue, 22 Dec 1992 19:12:03 GMT
  8. Message-ID: <1992Dec22.191203.24274@cbnewsm.cb.att.com>
  9. X-Newsreader: TIN [version 1.1 PL8]
  10. References: <1h5pseINNkvu@agate.berkeley.edu>
  11. Sender: news@cbnewsm.cb.att.com (NetNews Administrator)
  12. Nntp-Posting-Host: grenache.cnet.att.com
  13. Lines: 78
  14.  
  15. John Ousterhout (ouster@sprite.Berkeley.EDU) wrote:
  16.  
  17. : I'm about to start in earnest on the Tcl 7.0 release (first I'll
  18. : probably put out a Tk 3.1 release to fix all the bugs people are
  19. : finding with 3.0).  Thanks for all the input that many of you
  20. : provided in response to my draft of possible changes for 7.0.
  21. : There's still one issue I haven't been able to resolve, having to
  22. : do with the implementation of math functions like sin and cos.  This
  23. : message explains the issue and then asks for a vote from those of
  24. : you that care.
  25.  
  26. : There are two possible ways to implement math functions: embedded into
  27. : expr or as separate commands, and I can't make up my mind about which
  28. : way to do it.
  29.  
  30. : In the embedded implementation, the syntax of expressions gets extended
  31. : with functional notation for all the math functions so that you can say
  32. : things like
  33. :     expr {$x*sin(2*$theta) + $y*cos(2*$theta)}
  34.  
  35. : In the command implementation, each math function becomes a separate
  36. : command.  These commands would allow not only numbers but arbitrary
  37. : expressions as arguments, and produce floating-point string results,
  38. : so the expr command above would look like this instead:
  39. :     expr {$x*[sin 2*$theta] + $y*[cos 2*$theta]}
  40.  
  41.  
  42. I've done both implementations, at first creating new Tcl commands 
  43. and then as an extension to "expr".  I think the extension to expr
  44. is the cleaner, more natural method.
  45.  
  46. One of the things that makes Tcl a good extension language is that its
  47. syntax is easy to learn.  Command languages need to be simple and the
  48. Tcl command set should not be another hurdle for users. It's hard
  49. enough getting users for a new tool or application, without making
  50. them read a bunch of manual pages.
  51.  
  52. New users are already bothered by new syntax. And they get confused by
  53. the nested commands in expressions. But for the most part, they're already
  54. comfortable with expressions like a+b*sqrt(c).
  55.  
  56. It's also natural to think of these functions as extensions of the
  57. "expr" command.  They both take numeric expressions and observe
  58. precedence rules.  Unlike the command implementation, you don't have 
  59. to remember which commands can take expressions and which ones can't.
  60. You generally use these functions in conjunction with "expr" anyways. 
  61.  
  62. I think it's important that the Tcl command set remain small.
  63. I find it easier to remember hierarchic commands like "string" 
  64. and "file" than their flattened cousins like "lappend" and "llength".
  65. Adding 10-20 extra commands is more to remember.
  66.  
  67. The command approach muddies the Tcl name space and can provide naming
  68. conflicts.  For example, I may have a journaling command called "log".
  69. And what about the ambiguity between math function "exp" and "expr"?
  70. Save the Tcl name space for application-related commands and procs.
  71.  
  72. The command approach is less efficient but also can be less accurate.
  73. Rounding errors can be generated, as values are converted back to
  74. ASCII strings.  Given an adjustable floating point conversion (as in
  75. Tcl 7.0), this is admittedly rare.  But it can still very hard to
  76. track down, especially if you are expecting double precision
  77. arithmetic.
  78.  
  79. And as icing on the cake, the embedded functions automatically work 
  80. with "if", "while", etc.
  81.    
  82.     if { floor(log10($x)) > 2 } { 
  83.  
  84. as opposed to 
  85.  
  86.     if { [floor [log10 $x]] > 2 } {
  87.     
  88.  
  89. --gah
  90.  
  91.  
  92.  
  93.