Re: smob calling (Re: mildly incompatible change)

[Keith Wright <kwright@tiac.net>]

> From: Telford Tendys <telford@triangle.triode.net.au>
> 
> >        The CALL method is called when our object appears in functional
> >        position.
> 
> This seems really useful and could be the basis for making guile more
> object oriented. Unfortunately there are so many proposals for object oriented
> scheme extensions that it is almost scary to meet yet another proposal.

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 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.  But the
real question is do these new objects have powers so radical that they
break important global properties of the language.

R5RS, section 3.2, gives a list of nine type predicates (e.g. number?,
procedure?), and says that the empty list satisfies none of them.
Guile smobs have traditionally also satisfied none of them.  I think
"callable smobs" should satisfy the procedure? predicate.

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, but
removing this restriction is not creating a radicaly new "abnormal"
object.

I argue against myself: It is an important global property of Scheme
that if an object is a procedure, then there is _nothing_ that can be
done to it except call it, or pass it around as an atomic datum.
(Why is that important?)

Jim Blandy <jimb@red-bean.com> writes:
> However, I tend to think it's better to just add a completely separate
> tag for foreign functions; I'm not sure it's so good to make ordinary
> data objects callable that we should make it so easy.

I'm not sure what this means.  In Scheme, procedures _are_ ordinary
data objects.  Are you saying all foreign functions should be the
same type?  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.

-- 
     --Keith

This mail message sent by GNU emacs and Linux.
Food, Shelter, Source code.