Re: smob calling (Re: mildly incompatible change)

[mike@olan.com (Michael N. Livshin)]

Keith Wright <kwright@tiac.net> writes:

> It would be scary to see another proposal like "let's add this and
> that special syntax, and new objects with special evaluation rules,
> except when...".  But this one may be more like "let's eliminate the
> restriction on procedures written in C that forces every one of them
> to be named by a global variable".

There's no such restriction.

>From procs.h:

extern SCM scm_make_subr_opt SCM_P ((char *name, int type, SCM (*fcn) (),
				     int set));

If the last parameter is 0, no binding is performed.  In that case,
the first parameter is still interned as a symbol and is used solely
for documentation/debugging purposes (oh, and if there was a function
bound to this name, it'll be promptly and silently unbound :).

> > There is a slight additional problem that having smobs with a magic CALL
> > ability means that the smob has powers that are impossible to duplicate with
> > normal guile objects (or am I wrong?). I don't like the idea of extensions
> > to the language being above the normal limitations and rule of that language.
> 
> There is a sense in which almost any smob has powers not shared by "normal"
> objects, otherwise you would not have bothered to write it in C.

Yes.

> Now is a callable smob anything more than a procedure (closure) whose
> code is written in C, and whose environment is represented by a C data
> structure?  In the past, C procedures had to be assigned to global
> variables, and so their environment could have no local state,

Not exactly.  The procedure was visible, yes (although you could bind
it to a name like (string->symbol " my name begins with a space"), so
that no sane program would stomp on it).  But if the procedure was
intended to be wrapped in a "compiled closure" and made explicit
references to cclo's environment, it simply wouldn't work when called
by the bound name.

And in Guile you can create anonymous procedures, so life is good :).

Think Scheme.  You have the ability to make anonymous functions, you
have the ability to make closures, you have the ability to bind them.
Turing-wise, you are all set :).

> In Scheme, procedures _are_ ordinary
> data objects.

Depends on the meaning of "ordinary".  You can't look inside
procedures, all you can do with them is call and pass around.  I think
here "ordinary" is opposed to "opaque".

> Are you saying all foreign functions should be the
> same type?

I don't think so - it would be a bad idea, given the current
evaluator.  If you introduce a distinct type for foreign functions at
all (the usefulness of which I don't see, BTW), you'll want to further
differentiate them by arity.  And there are only two tc7 tags left :).

> Or that all smob types should satisfy further disjoint
> predicates and so should _not_ satisfy procedure? ?  Or that procedure
> types should be inscrutable, as in the above counter argument.

Hmm.  CLOS has "funcallable" metaclass or some such.  Perhaps it has a
reason for that.

In general, the ability to associate arbitrary data with procedures
can be useful, but you don't have to tweak the evaluator or twist the
Scheme semantics to achieve this effect.  In Guile, you can use
procedure properties.  That's how I implemented generics in Pint, BTW.
Procedure properties (or, indeed, the whole concept of arbitrary
external object properties) are, IMHO, a straightforward and simple
language extension.  Procedures remain procedures and don't feel bad
about it :).

>      --Keith

mike.