home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / lang / tcl / 2199 < prev    next >
Encoding:
Internet Message Format  |  1992-12-22  |  2.8 KB
  1. Path: sparky!uunet!think.com!ames!agate!sprite.Berkeley.EDU!ouster
  2. From: ouster@sprite.Berkeley.EDU (John Ousterhout)
  3. Newsgroups: comp.lang.tcl
  4. Subject: Advice wanted on math functions for Tcl 7.0
  5. Date: 22 Dec 1992 01:09:34 GMT
  6. Organization: U.C. Berkeley Sprite Project
  7. Lines: 50
  8. Distribution: world
  9. Message-ID: <1h5pseINNkvu@agate.berkeley.edu>
  10. NNTP-Posting-Host: tyranny.berkeley.edu
  11.  
  12.  
  13. I'm about to start in earnest on the Tcl 7.0 release (first I'll
  14. probably put out a Tk 3.1 release to fix all the bugs people are
  15. finding with 3.0).  Thanks for all the input that many of you
  16. provided in response to my draft of possible changes for 7.0.
  17. There's still one issue I haven't been able to resolve, having to
  18. do with the implementation of math functions like sin and cos.  This
  19. message explains the issue and then asks for a vote from those of
  20. you that care.
  21.  
  22. There are two possible ways to implement math functions: embedded into
  23. expr or as separate commands, and I can't make up my mind about which
  24. way to do it.
  25.  
  26. In the embedded implementation, the syntax of expressions gets extended
  27. with functional notation for all the math functions so that you can say
  28. things like
  29.     expr {$x*sin(2*$theta) + $y*cos(2*$theta)}
  30.  
  31. In the command implementation, each math function becomes a separate
  32. command.  These commands would allow not only numbers but arbitrary
  33. expressions as arguments, and produce floating-point string results,
  34. so the expr command above would look like this instead:
  35.     expr {$x*[sin 2*$theta] + $y*[cos 2*$theta]}
  36.  
  37. Here are the tradeoffs between the two approaches, as I see them:
  38.  
  39. 1. The embedded approach avoids having to add a lot of commands (10-20)
  40.    to the command name space and uses the normal functional syntax that
  41.    people are used to in expressions in other languages like C.
  42. 2. By putting the functions into expr, there is less conversion to and
  43.    from ASCII, which is more efficient (ASCII conversion is pretty slow
  44.    on most machines).  In the second example above, the results of the
  45.    sin and cos commands have to be printed in ASCII, then reparsed by
  46.    expr;  in the first example the only conversion to ASCII is when expr
  47.    creates its result.
  48.  
  49. 3. The command approach avoids adding additional syntax to the expr
  50.    command and uses the normal command-substitution mechanism that
  51.    people are used to in Tcl.
  52. 4. In the command approach it's possible to use the individual math
  53.    functions separately without having to go through expr.  For example,
  54.    you could say "set a [cos $x]", whereas in the embedded approach
  55.    you'd have to say "set a [expr cos($x)]"
  56.  
  57. If you have a preference between these two schemes, please send me a
  58. message with your vote.  All it needs to say is "Embedded" or
  59. "Separate commands".  If there is a strong sentiment one way or the
  60. other then I'll go with the majority.  Otherwise I may have to flip
  61. a coin.
  62.