home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / lang / tcl / 2489 < prev    next >
Encoding:
Text File  |  1993-01-28  |  2.5 KB  |  69 lines
  1. Newsgroups: comp.lang.tcl
  2. Path: sparky!uunet!eco.twg.com!twg.com!news
  3. From: "David Herron" <david@twg.com>
  4. Subject: Re: Multiple Interpreters
  5. Message-ID: <1993Jan28.173729.29095@twg.com>
  6. Sensitivity: Personal
  7. Encoding:  49 TEXT , 4 TEXT 
  8. Sender: news@twg.com (USENET News System)
  9. Conversion: Prohibited
  10. Organization: The Wollongong Group, Inc., Palo Alto, CA
  11. Conversion-With-Loss: Prohibited
  12. Date: Thu, 28 Jan 1993 17:37:28 GMT
  13. Lines: 54
  14.  
  15. omar@wucs1.wustl.edu asks:
  16. >I know there must be many good uses for having multiple interpreters, but
  17. >I can't seem to think of any.
  18.  
  19. Louis is right that the basic advantage is in separate namespaces.
  20.  
  21. What originally inspired me to do `interp' was a comtemplated
  22. port of Tk/TCL to DOS (using an Xlib implementation called X/DOS).
  23. With X/DOS as it is(was at that time) you'd only be able to run one
  24. TK application at a time.  But if multiple interpretors could be
  25. run, then multiple TK app's could be run.
  26.  
  27. The current `interp' is unable to do this.  Olav's interp module should
  28. let you do it, if I read it right.
  29.  
  30.  
  31. If you look at the internals of servicemail you see it starts a
  32. new TCL interpretor for every message it processes.
  33.  
  34.  
  35. louie@sayshell.umd.edu (Louis A. Mamakos)
  36. > Actually, it would be great if a new interpreter could inherit
  37. > methods/commands from the "super class" or the interpreter that
  38. > created it, but I can see how that might be difficult to implement.
  39.  
  40. You're right that it would be difficult to do automatically.  However,
  41. there's a way to do this manually with the existing interp.  You create
  42. the interpretor like so
  43.  
  44.     interp newInterp
  45.     newInterp -setParent parentInterp
  46.  
  47. `unknown' looks for unknown commands in its parent before it looks
  48. in MainInterp.  Yes that's not quite the same thing as inheritance.
  49. The other inheritance facility is `-chainCommand' (if someone can suggest
  50. improved names for these things, I'm all ears...).  Again, it's manual
  51. but works like:
  52.  
  53.     interp newInterp
  54.     foreach cmd { a list of commands to inherit } {
  55.         newInterp -chainCommand $cmd parentInterp
  56.     }
  57.  
  58. I believe that sufficient facilities are in the interp module for lots
  59. of interesting things.  They aren't automatic (which kinda follows
  60. the tcl tradition of coding the raw facilities in C leaving the niceties
  61. to tcl procedures) however.
  62.  
  63. What I don't know is if they're complete (enough) or well named.
  64.  
  65. <- David Herron <david@twg.com> (work) <david@davids.mmdf.com> (home)
  66. <-
  67. <- "That's our advantage at Microsoft; we set the standards and we can change them."
  68. <- Karen Hargrove of Microsoft quoted in the Feb 1993 Unix Review editorial.
  69.