Article View: comp.lang.misc
Article #7024API design...
From: Peter da Silva
Date: Fri, 11 Nov 1994 00:37
Date: Fri, 11 Nov 1994 00:37
53 lines
3327 bytes
3327 bytes
In article <5614.imc@uk.ac.ox.prg>, Ian Collier <imc@comlab.ox.ac.uk> wrote: > RexxRegisterSubcomExe(PSZ envname,RexxSubcomHandler *handler,PUCHAR userarea); > RexxRegisterFunctionExe(PSZ funcname, RexxFunctionHandler *handler); > RexxRegisterExitExe(PSZ name, RexxExitHandler *handler, PUCHAR userarea); > When a program in the extension language is started it will be able to send > commands to the application with the instruction > address envname "a command to be sent to the application" The problem here is that the application has to include it's own mini- interpreter (a simple one, that just has to tokenize command lines) to link to REXX. Tcl at least takes on the responsibility for breaking down arguments into strings, though this isn't ideal. The ideal API would pass a vector of type-value pairs, with "type" at least including "string" and "integer". A routine when it registered with the interpreter would specify a template specifying: 1. How many arguments it expected. 2. What the names of those arguments are. 3. What types were legal for each argument. Plus: 4. An argument (with a name) to receive a vector of remaining arguments. The reason for providing a name is to allow the language to provide a meaningful error message if the types of the argument don't match, and to allow for languages that have tagged-argument semantics to functions. Every routine should be able to accept one of either "string" or "integer" values for each argument, at a minimum. That way the existing Tcl and Rexx glue can be easily adapted. For Rexx, both commands and functions could be glued to this same API. For the sake of Perl and Scheme it would be useful to be able to pass (or specify) a closure which a routine would treat as an opaque object to be passed back to the execution engine. The return value from this call on the interpreter would be another type/value pair for the routine to use. Finally a "not provided" and "error" types would be used to allow for optional arguments and failure returns from the execution engine. This would cover Scheme's call/cc, Perl's sub and eval, and Tcl's eval, as well as callbacks in Tk and like packages. Have I missed anything? -- Peter da Silva `-_-' Network Management Technology Incorporated 'U` 1601 Industrial Blvd. Sugar Land, TX 77478 USA +1 713 274 5180 "Hast Du heute schon Deinen Wolf umarmt?"
Technical Details
Message-ID:
<id.CGME1.VCB@nmti.com>Path:
arc1-ca.pugleaf.net!nntp.gmd.de!xlink.net!news.dfn.de!swiss.ans.net!gatech!swrinde!news.uh.edu!uuneo.neosoft.com!nmtigw!peterReferences:
<398tet$9lp@csnews.cs.Colorado.EDU> <39odfp$nvq@love.loyola.edu> <NJ104.94Nov9121749@hilsa.amtp.cam.ac.uk> <5614.imc@uk.ac.ox.prg>Show Full Headers
Complete Article Headers
X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f891f,9bda08f2f068881f X-Google-Attributes: gidf891f,public X-Google-Thread: 1025b4,9bda08f2f068881f X-Google-Attributes: gid1025b4,public X-Google-ArrivalTime: 1994-11-11 02:21:31 PST Newsgroups: comp.lang.misc,gnu.misc.discuss Path: arc1-ca.pugleaf.net!nntp.gmd.de!xlink.net!news.dfn.de!swiss.ans.net!gatech!swrinde!news.uh.edu!uuneo.neosoft.com!nmtigw!peter From: peter@nmti.com (Peter da Silva) Subject: API design... Message-ID: <id.CGME1.VCB@nmti.com> Sender: peter@nmti.com (peter da silva) Organization: Network/development platform support, NMTI References: <398tet$9lp@csnews.cs.Colorado.EDU> <39odfp$nvq@love.loyola.edu> <NJ104.94Nov9121749@hilsa.amtp.cam.ac.uk> <5614.imc@uk.ac.ox.prg> Date: Fri, 11 Nov 1994 00:37:51 GMT Lines: 53