Path: utzoo!attcan!uunet!ogicse!decwrl!ucbvax!parc.xerox.com!janssen From: janssen@parc.xerox.com (Bill Janssen) Newsgroups: comp.soft-sys.andrew Subject: Re: Meta-X package Message-ID: Date: 27 Jul 90 04:59:54 GMT References: <3756@auspex.auspex.com> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 44 Excerpts from ext.andrew: 26-Jul-90 Re: Meta-X package Guy Harris@uunet.uu.net (3112) > >[A reply to Fred Hansen's posting about using ESC-ESC and Ness, turning > into a discussion about passing args to procs] The proc system in ATK is unfortunately designed to be called by a keystroke and/or menu item on some kind of view. The notion is that a single arg can be passed, through the Emacs standard of typing ^U argument before invoking the function (the function im_ProvideArg() can also be called to set the argument value). The function can then call im_Argument() to retrieve the argument, which is passed as a long. But in general, ATK procs are argument-less functions designed to be called by user actions, that often prompt for input from the user. This severely limits their usefulness in extension languages, such as Ness. GNU Emacs has a triple model: 1) Internal procedures are coded in C, and are meant to be called from C code. These correspond to module-private functions. 2) Elisp functions are coded in C or Elisp, and are meant to be called from the extension language (Elisp). These are more like the exported interface provided by the ATK .ch files. Almost all Emacs functionality is available through these, including many low-level primitives. 3) A special set of procedures, corresponding to ATK procs, are defined to be called by the user. These wrap a different interface around some set of the Elisp functions. A stylized approach to defining them ensures that they prompt for possible arguments, if such are defined. They may also be called from Elisp. This middle layer seems to be what ATK is missing. I think if one were to re-do such a project, having an extension language (Scheme sounds nice) in mind from the beginning, and implementing part of the application in the extension language, would be a good idea. Such a layer can be added after the fact, though. Ness almost does it right; it can call Class methods as well as procs. But is has to re-parse the .ch file each time the function is interpreted (I think), which makes for slow execution. I think the class compiler should do the parsing and leave the results in another .dox file, in a form that could be easily loaded by the extension language. Bill