Re: [Sbcl-devel] Re: Request for suggestions on callbacks API

[Brian M. <bma...@cs...>]

On Mar 5, 2005, at 9:54 AM, Thomas F. Burdick wrote:

> Brian's list of things needed before merging callbacks looks
> remarkably like my to-do list for them, so I guess this is a good
> argument for making code publicly available, even if it's incomplete
> and inconsistent.  Well, fixing the comment/code mismatch was the top
> of my list, and reforming the code as a patch last (ie, I wasn't
> planning on doing that until I was actually proposing to merge it).

I guess this is a good indication that I didn't miss anything! 
Integrating callbacks has been on my own todo list for months as well, 
so I figured that I might as well get a discussion started about what 
parts of the process require discussion, so I can push on this a little 
in parallel with my other projects.

> I agree the current naming scheme is horrible.  In a previous CMUCL
> implementation, I'd called such things ALIEN-CALLABLEs, and I was
> planning on changing the naming scheme to that.  IMO, ALIEN-CALLABLEs
> really should be called ALIEN-FUNCTIONS or -ROUTINES, and should be
> defined with DEFINE-ALIEN-ROUTINE, but since that would involve an
> aweful lot of change and breaking of existing code,
> DEFINE-ALIEN-CALLABLE is probably good enough.

I think define-alien-routine makes a lot of sense: it's a routine which 
is alien. define-alien-callable works from that point of view (it 
defines a callable which is at least partially alien) and also 
indicates that it defines something which is callable from alien code. 
I think that the other suggestions that I've heard have been more 
confusing and less brief, so this one wins by default.

> ALIEN-CALLABLE-ALIEN is really just a gross hack around the
> implementational detail that ALIEN-CALLABLE objects aren't proper
> alien objects.  As such, I'd like to see that function clearly marked
> as depricated; or, even better, ALIEN-FUNCALL could be taught to do
> the right thing with an ALIEN-CALLABLE object.

Do ALIEN-CALLABLE objects really need to be TYPEP 'SB-ALIEN:ALIEN? I 
would guess that the alien functions could do the right thing with an 
ALIEN-CALLABLE without trying to make these types one and the same. In 
this case, alien-callable-alien would need to stick around as an 
accessor.

But maybe this isn't necessary: are linkage table entries set up as the 
right ALIEN type? Ideally, callables would go through linkage-tables.

> The incompatible-redefinition condition really is necessary.  If you
> redefine an alien-callable such that its function signature isn't
> compatible with its old one, the implementation should really tell
> you.  Maybe that's okay, and existing calls will still work, but only
> the programmer can be in a position to know.  It's probably overly
> strict on non-PPC architectures, though.

OK. In this case we don't issue a special condition type for existing 
alien incompatible redefinition problems. I would prefer to see all 
incompatible-redefinition alien warnings go through the same condition 
type, so this should either be added to all of alien or not at all. 
We're getting close to 0.9 and the march to 1.0, so I'd like to see 
MORE CONSISTENCY and MORE BETTER APIs whenever possible :-)

> I don't like the -makunbound name change for REMOVE-ALIEN-CALLABLE
> because that doesn't make much sense for cases like:
>
>   (let ((fn (alien-lambda ...)))
>     (do-something-with fn)
>     (alien-callable-makunbound fn))
>
> Maybe -unintern?  There isn't an ADD-ALIEN-CALLABLE only because
> that's what ALIEN-LAMBDA does.

-unintern seems too symbolish. I think INVALIDATE-ALIEN-CALLABLE is 
probably the best name. If we go through linkage tables, we can really 
invalidate the linkage table entry that was passed to the foreign code, 
and make it hit the undefined-alien trampoline when called.

> Sorry for leaving this orphaned, but finishing up old consulting
> contracts, a new job, and moving to Germany left me a little
> over-extended.  I'm glad to see it's getting dusted off.

I understand completely. It can be hard to attend to some of these "big 
projects" especially when input from others may be required. I'm trying 
to see some of these large but unfinished projects (callbacks and 
evaluator especially) pushed along when I can.

Later today I will make another module in SBCL CVS to contain the 
current version of the callables code. This way those of us with a 
commit bit can directly hack on the code until it's ready to merge, and 
those without have an up-to-date basis for sending patches.
--
Brian Mastenbrook
bma...@cs...
http://cs.indiana.edu/~bmastenb/