Re: Interactive support

["Greg J. Badros" <gjb at cs dot washington dot edu>]

"Marisha Ray & Neil Jerram" <mpriz@dircon.co.uk> writes:

> Greg J. Badros <gjb@cs.washington.edu> wrote...

<snip>

> I've taken a look at optargs.scm and am pleased to report that (IMO) the
> work that we've each done is almost entirely complementary.  Your code
> addresses (i) pulling an "(interactive ...)" specification out of the body
> of a closure definition, and (ii) reflection to select the current set of
> interactively invocable procedures, whereas mine is mostly concerned with
> defining, parsing and acting upon the interactive specification itself.

Excellent... that was the next bit I was going to have to look at.  (My
immediate motivation was just to distinguish procedures that have useful 
interactive semantics).

> The only point of conflict is that you store the spec as a procedure
> property while I encapsulate it inside a new closure.  Now that I know about
> procedure properties, I think that they're a better approach, as long as (i)
> procedure properties are going to stay in Guile (I vaguely remember people
> talking about removing procedure slots) and (ii) GOOPS generic functions
> will have properties as well, since some of them will also benefit from
> interactive specs (but per-function or per-method?).

Well, as long as we have the layer of abstraction below, it'll be easy
to update if things change out from underneath us, so we can stick with
p-ps for now.

> To tie our stuff together, I propose introducing a set-interactive!
> procedure -
> 
> (define (set-interactive! proc spec)
>   (set-procedure-property proc 'interactive (and spec
> (make-interaction-handler spec))))

I'd rather have a slightly longer name of
`set-procedure-interactive-spec!'.

> - modifying optargs.scm to use set-interactive! instead of (set-p-p
> 'interactive), getting rid of interactive-wrapper and make-interactive!, and
> adding a call-interactively.  Since all of SCWM's specifications are

Yes, this sounds good, though I've not read interactive.scm closely yet.

> currently just "(interactive)", there needs to be a make-interaction-handler
> method that handles an empty list correctly.

Definitely; interactive needs to be able to just designate a procedure
as being okay to invoke interactively.  call-interactively should throw
an error when invoked on a procedure not so marked.

> How does that sound?

I'm a little bit concerned about having a dependence on interactive.scm
from optargs.scm.  Maybe the optargs bundled with Scwm should be
optargs-interactive.scm (it's different than the optargs bundled with
Guile, now).  The problem with that is a maintenance problem between the 
core optargs functionality between the two modules.  It's possible to
factor that out, certainly, but I'm not sure if it's worth it.

Greg