🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.lang.misc
Article #7024

API design...

#7024
From: Peter da Silva
Date: Fri, 11 Nov 1994 00:37
53 lines
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!peter
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>

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