More on GuIfying the repl

[Ariel Rios]

>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!
The bonobo control is the main idea behind  guile-repl.
I intend it to be the easiest way to add guile scripting 
to an application. No libguile linking, no nothing.
You just add the component and that's it...  

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

Well. To do this you we'll also need the guile ORBit[1] bidings I am 
doing. 
 
>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?

I am not really sure what you mean with that.

>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.
This looks like a good idea. Marius?

> 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.
Not complety sure on this one. For the moment maybe we can
simple do (call-with-dynamic-root) if necesary...

> 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.
I also like this one. 

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

Now, my comments:

=I think guile-repl supercedes (is this the right word? (goes further?))
guile-gui. My aproach is intended for adding scripting and a graphicl
repl to C applications. Whilst guile-gui can also do this I think
it is harder for the non Guile literate to do this step.
-We can however offer almost the same behaviour for native Scheme
development (with expcetion of the bonobo component) since guile-repl
code interesting functionality is coded in scheme.
-Maybe, we can simply wrap GuileRepl inside guile-gtk (something  weird
I think) but can be achieved if we can separate all Scheme code from the
widget definition.
-Guile-repl is intended to be the basis of a Guile IDE =)


Update on guile-repl:
I have completed guile paren function in the eidtor, i.e. when
we close a parenthesis we select the region from the begin tp the end
of the parenthesis (like DrSchemes does)
I have removed some bugs
we now have a nice homepage (well, it's not nice but whatever...)

http://linux.cem.itesm.mx/~ariel/grepl.php

ariel