Re: smob calling (Re: mildly incompatible change)

[Jim Blandy <jimb@red-bean.com>]

> 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".

Well, that restriction should be existed, by separating scm_make_gsubr
into one function that produces a Scheme procedure object from a C
function, and another that assigns it to a global variable.

> 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.

Yes, all foreign functions should satisfy the PROCEDURE? predicate.

I think that if an object is callable, then applying it should be the
only thing you can do with it.  (Inspection of closures while
debugging is a separate issue.)

I could invent all kinds of things that applying a vector or a pair
might mean, that would make for groovy notation in some circumstances
(e.g., strings as glob predicates: ("*.c" "foo.c") => #t), but I think
that way lies chaos.

If we do relax this, I want to do it in some broader context.  For
example, there are some cute object systems where objects are
procedures and their first argument is a method identifier.  But
encouraging people to sort of invent their own as they go along seems
bad.