From: Neil Jerram <neil@ossau.uklinux.net>
Cc: Guile User Mailing List <guile-user@gnu.org>
Subject: Re: Newbie - desigining apps
Date: Sat, 09 Oct 2004 22:47:45 +0100 [thread overview]
Message-ID: <41685C81.2070507@ossau.uklinux.net> (raw)
In-Reply-To: 4165E98D.3090304@triad.rr.com
Max Polk wrote:
> I'm intending on moving forward with free software development and
> understand Guile is the official extensibility language of GNU, and that
> I ought to support it in my application. Makes sense, fine.
>
> Now for this to be useful at all, my application has to be designed from
> the beginning to accommodate external control. That's a big thing,
> writing an app that controls itself by traditional design, versus
> writing an app that is controlled from the outside.
>
> Have others found that supporting Guile in an application means
> rethinking how it runs at it's very core? For example, instead of
> writing use cases and designing from that, now I have a use case like
> "let the user call any higher-level function".
>
> Even worse, what about object orientation? Is it possible to let the
> user create, then assemble together, use, then destroy various program
> objects, all from Guile? And how is even that done, returning C++
> objects back to Guile -- I assume you would have to return a handle
> representing the internal program object, then add some management layer
> that maps these handles to internal objects.
>
> WOW! This is a radically new approach to software development!
>
> Can someone can start me off on the right foot?
I'll have a go ... I'd say the main thing is to be clear on why you
want to add Guile to your application. There is one good reason, for
example, that may have nothing to do with extensibility, namely that you
yourself simply prefer programming in Scheme to programming in C. In
this case (and assuming that there is something that ties you to C, such
as needing to interface to existing code), the trick is to create a
C<->Scheme interface as close as possible to your existing code, and
then use the Scheme side of this interface to write the rest of the
application in Scheme. In this case the high level control design in
Scheme may be essentially the same as it would be if you had written in
C. (Modulo functional/imperative style differences and continuations,
which can turn an event-driven program inside out if you choose to use
them.)
On the other hand, if it _is_ extensibility that you are after, by
definition that means that you expect other people to code things that
are not in the core application, but you presumably have some idea of
the kind of extensions that you want to enable them to write?
I could say more by offering some examples, but it probably makes most
sense for you to say a bit more about your application first, so that
the discussion can be more targeted.
Regards,
Neil
_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user
prev parent reply other threads:[~2004-10-09 21:47 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-10-08 1:12 Newbie - desigining apps Max Polk
2004-10-08 2:49 ` Julian Graham
2004-10-08 18:43 ` Anthony Kozar
2004-10-09 21:47 ` Neil Jerram [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=41685C81.2070507@ossau.uklinux.net \
--to=neil@ossau.uklinux.net \
--cc=guile-user@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).