🚀 go-pugleaf

In article <BOBO.94Nov15114920@avogadro.arc.nasa.gov> bobo@avogadro.arc.nasa.gov (Mark Friedman) writes:

   I hate to get into one of these he said / she said discussions, but I
   certainly do not agree that ILU supports first class procedures. 

I suppose it depends on what you mean.  All procedures, in any
program, are associated with some context or state.  Different
invocations of a procedure may need or assume different execution
contexts.  This is less apparent when working in a single-threaded
environment, but still true: for example, global variables that the
procedure refers to may have different states as the process executes.
In a multi-threaded or multi-process environment, this context can
become quite intricate.

In ILU, we package this context up into an ``object'', and attach it
to the procedure.  This allows us to safely pass procedures across
interfaces.  However, the representation of this procedure+context may
not match the "normal" procedure representation of more primitive
programming languages such as ANSI C, where an ILU procedure is
represented as a C procedure plus a pointer to a bundle of context.
This means that the ILU procedure

  Procedure1 (arg1 : Type1) : ReturnType

is mapped in C to the procedure

  I_ReturnType I_ContextType_Procedure1 (
    I_ContextType context,	/* the execution context */
    ILU_C_Environment *e,	/* a way of signalling exceptions */
    I_Type1 arg1);		/* the actual argument */

(where ``I'' is the name of the interface module in which Procedure1
is defined, like a C++ namespace or Lisp package).  Since ILU
procedures can raise exceptions, and C procedures cannot, another
extra argument is needed to implement a mechanism to handle this
additional ability mismatch.  Perhaps another way to say this is that
ILU supports first-class ILU procedures, but not first-class C
procedures.

   The reason that I want this is so that I can pass arbitrary Lisp
   callbacks to C functions whose source code I have no access to. The
   callback has to just look like a C function.

Yep, I understand.  I've attached an example of how to do it with ILU;
basically a bit of impedance-matching code is needed.  It's messy, and
what I was thinking of was to have ILU generate some of the code to
make it less messy.  In languages with real closures, of course, it
could be much prettier than in C.  Note that if the widget kit's
callback procedure doesn't allow you to associate some arbitrary
user-specified data with the callback (most do), this approach won't
work.

Here's the way to do it in ILU:

(*--------- in ISL: *)

(* Assume that the C function is some button callback exported by
   some widget toolkit, that has the C signature

     void (*) (Type1 arg1, void *userdata);

  We have to decide what kind of user data we want to pass before
  writing the ISL for this.  Let's use "Type2".
*)
INTERFACE I;
TYPE Type2 = INTEGER; (* just for instance *)
TYPE Callback = OBJECT
 METHODS
  Invoke (arg1 : Type1, userdata : Type2)
 END;

(*--------- in Lisp: *)

(defclass callback.impl (i:callback)
 ((callback-fn)))
(defmethod i:invoke ((self callback.impl) arg1 ar2)
  (funcall (slot-value self 'callback-fn) arg1 arg2))

(defun some-callback-fn (arg1 arg2)
  (do something))	; innovative use of do macro!

(make-instance 'callback.impl
  :callback-fn #'some-callback-fn)

(*--------- in C: *)

/* we need to define a dummy callback proc, and dummy data struct,
   to match those required by the widget set with those allowed by
   ILU */

typedef struct {
  I_Callback obj;
  I_Type2 userdata
} callback_closure;

callback_closure *make_callback_closure (I_Callback obj, I_Type2 userdata)
{
  callback_closure *c = (callback_closure *) malloc(sizeof(callback_closure));
  if (c != NULL)
    {
      c->obj = obj;
      c->userdata = userdata;
    }
  return (c);
}

void generic_callback (I_Type1 arg1, void *user_data)
{
  ILU_C_Environment exception_context;

  I_Callback_Invoke (((callback_closure *) user_data)->obj,
		     &exception_context,
	             ((callback_closure *) user_data)->userdata);
  /* Since our widget set doesn't know what to do with exceptions
     anyway, we'll just ignore them!  Isn't C programming grand?  */
}

void set_callback (I_Callback callback_obj, I_Type2 somedata)
{
  SomeWidgetKit_set_callback (widget, W_BUTTONDOWN,
    generic_callback, make_callback_closure (obj, somedata));
}

Bill
--
 Bill Janssen  <janssen@parc.xerox.com> (415) 812-4763  FAX: (415) 812-4777
 Xerox Palo Alto Research Center, 3333 Coyote Hill Rd, Palo Alto, CA  94304
 URL:  ftp://parcftp.parc.xerox.com/pub/ilu/misc/janssen.html