Re: More on GuIfying the repl

[Neil Jerram]

>>>>> "Ariel" == Ariel Rios <address@hidden> writes:

    >> guile-repl goes further than the other approaches in defining a
    >> Bonobo component interface for a Guile REPL and using the
    >> GuileRepl widget to implement this interface.  This is cool!
    Ariel> The bonobo control is the main idea behind guile-repl.  I
    Ariel> intend it to be the easiest way to add guile scripting to
    Ariel> an application. No libguile linking, no nothing.  You just
    Ariel> add the component and that's it...

This is cool, although I think that some applications might want to
embed only part of GuileRepl, not necessarily all of it.  Some
applications might not want the editor widget, for example.

    >> I would be very interested in this: ideally, the mechanism
    >> necessary to say "I want to provide an implementation of this
    >> interface, and here it is" would be exported to the Scheme
    >> level, so that no C code is required for a new interface
    >> implementation.

    Ariel> Well. To do this you we'll also need the guile ORBit[1]
    Ariel> bidings I am doing.

Great!  I'm not ready to look at this myself yet, though, since I have
nowhere near a complete Gnome dev setup.
 
    >> On a detailed level, I think there is one issue with the
    >> specified interface.  Namely, what is the relationship (current
    >> module etc.)  between Scheme expressions evaluated by the REPL
    >> inside the interface and other evaluation performed by the
    >> application outside the interface?

    Ariel> I am not really sure what you mean with that.

Is evaluation in the rest of the application performed in the same
environment and current module as evaluation in the REPL?  (Or perhaps
there isn't any evaluation in the rest of the application?)

    >> 3.4. Combinations

    >> Extend boot-9.scm's REPL code so that it can be used in a
    >> non-blocking way like the (gtk event-repl) REPL engine.  This
    >> should completely obsolete the (gtk event-repl) code.
    Ariel> This looks like a good idea. Marius?

I'm thinking about how to do this as well.

    >> To avoid using explicit continuations (if so desired), use
    >> guile-gui's widgets with paren matching and history handlers
    >> (but not as a port) as the front end for a non-blocking REPL.
    Ariel> Not complety sure on this one. For the moment maybe we can
    Ariel> simple do (call-with-dynamic-root) if necesary...

I don't understand how `call-with-dynamic-root' is relevant here -
please explain.

    >> Use (gtk event-repl) or the non-blocking extension of the
    >> boot-9.scm to provide a more sophisticated REPL than
    >> gh_eval_str_with_standard_handler for the guile-repl widget.
    Ariel> I also like this one.

Fine.

    >> Compare and maybe interchange parenthesis matching algorithms
    >> between guile-repl and guile-gui.
    Ariel> Agreed. Basically the only thing I do want to provide in C
    Ariel> is the GtkWidget definition and the bonobo control. At this
    Ariel> moment almost all of the algorithms are already in Scheme

I need to have a look at your latest changes.

    Ariel> Now, my comments:

    Ariel> =I think guile-repl supercedes (is this the right word?
    Ariel> (goes further?))  guile-gui.

I'd be very happy for it to do so, but I don't think it supersedes
guile-gui just yet.  For my tastes, there are three reasons why I
would currently prefer to continue working with guile-gui.

1. guile-repl is too monolithic.  It provides a single
   take-it-or-leave-it composite widget.  My preference is to provide
   components of the smallest sensible size - such as (gui entry-port)
   - so that both one's own package and other people can build them up
   in their own ways.

2. guile-repl is dependent on a Gnome dev environment.  Again,
   breaking things down into smaller pieces would help here.  The
   GuileRepl widget proper only requires Gtk and so could be packaged
   as non-Gnome-specific.  Obviously the Bonobo aspect does need Gnome
   (or at least some of it), so this should be packaged as an extra
   which builds on the widget package.

   In the same vein, I note that CVS guile-gtk currently doesn't build
   because of Gnome problems.  IMO this is a significant bug.

3. guile-repl has too high a `hacktivation enery' because a lot of it
   is written in C.  This is obviously just my opinion, and I need to
   check out your latest changes, but that was my feeling when I last
   looked.

    Ariel>                              My aproach is intended for
    Ariel> adding scripting and a graphicl repl to C
    Ariel> applications. Whilst guile-gui can also do this I think it
    Ariel> is harder for the non Guile literate to do this step.

I agree - Bonobo is a Good Thing.  But the interfaces should be
defined in such a way that multiple implementation are possible.

    Ariel>                                                        -We
    Ariel> can however offer almost the same behaviour for native
    Ariel> Scheme development (with expcetion of the bonobo component)
    Ariel> since guile-repl code interesting functionality is coded in
    Ariel> scheme.

I don't see the necessary connection between Scheme implementation and
use for Scheme development.

    Ariel>          -Maybe, we can simply wrap GuileRepl inside
    Ariel> guile-gtk (something weird I think) but can be achieved if
    Ariel> we can separate all Scheme code from the widget definition.

I think it would make good sense to add REPL and port-related widgets
to guile-gtk (and to ensure that guile-gtk as a whole is
Gnome-independent).

    Ariel> -Guile-repl is intended to be the basis of a Guile IDE =)

Quite; guile-gui too!

Regards,
        Neil