Linas Vepstas <linasvepstas@gmail.com> writes:

> Basically, if you are going to let users enter arbitrary scheme into
> your app, they *will* enter malformed, broken expressions, and you
> have to deal with these.  Among other things, you have to give them
> a clue as to what the error was -- some sort of trace, error reporting.
>
> For me, this was implementing a REPL loop look-alike in my app.
> I can't say "work-alike", I think mine *almost* works-alike, but not sure.
>
> It took me a *long* time to figure out I needed the pre-unwind version
> of things, and even then, it took me a fair amount of effort to figure
> out what to put in there.
>
> Having a section showing how to implement a repl-work-alike loop
> in one's app, with reasonable debugging/stack-printing output,
> would be nice to have.  Figuring out how to do this one one's
> own requires a lot of tenacity.

Guile 2.x would be hugely more attractive as an extension language if
there were some higher-level interfaces for application developers.  In
gEDA, we have to use a ridiculous amount of C code just to set things up
so that user-provided Scheme expressions can't leave the user staring at
a command prompt wondering where the last hour's work disappeared to
(and even that's not as reliable as we'd like).

Ideally, there should be:

 - An easily re-usable/embeddable and well-documented REPL, to aid
   developers in implementing a "Scheme Interaction Window" or similar
   in their apps.

 - An high-level API for passing strings for evaluation, that reports
   back the results or error information in a way that's easy to deal
   with from C.

In a perfect world, these would be part of the same API. ;-) I believe
that these would actually be applicable to the majority of use-cases of
libguile.

Cheers,

                                 Peter

-- 
Peter Brett <peter@peter-b.co.uk>
Remote Sensing Research Group
Surrey Space Centre