Newbie - desigining apps

Newbie - desigining apps

[Max Polk]

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?



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: Newbie - desigining apps

[Julian Graham]

Hi Max,
  It might help the people on this list to have a little bit more
information about the type of application you're trying to write.  For
the sake of my response, I'm going to assume it's an application where
some degree of extensibility makes sense -- it goes without saying
(although I guess I'm saying it) that just because Guile is the
recommended extensibility language for Free Software projects doesn't
mean you need to support it in your Free Software project.
  To your specific questions:

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

  There are some basic requirements for using Guile in your code that
are going to affect the "core" -- the most obvious example is that
you'll probably need to wrap most of the functionality of your current
main() in the function called by scm_boot_guile().  Second, if you
really do want to make it possible to let users call "core" functions
from Guile Scheme code, you'll need to make these functions (or
wrappers around them) able to handle Guile's SCM type.  (Making your
software Guile-controllable may require enough work that you may find
it not much more difficult to provide an abstraction layer that would
let your "higher-level functions" be accessed by a variety of
different user interfaces, not just Guile.)
  In terms of use-cases, the Guile manual describes a few different
ways that people tend to want to use Guile.  A couple of the most
common are: Using Guile to provide a built-in Scheme interpreter for
your application -- .e.g., you're writing a spreadsheet and need a
language for people to write formulas in and a way to evaluate
expressions in those formulas; vs. what you seem to talking about,
which is providing a set of C functions that do something and using
Guile as a way to access them and use them in conjunction with
pre-existing features of Scheme and libraries of Scheme code.

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

  Yes, it is possible to let users construct relatively complex types
from Guile and pass them to and from C++ code.  You do this by
explicitly exposing (via a Guile API call) the type to Guile and
providing some basic information to Guile on how to display it /
garbage-collect it / etc.  You'll want to consult the Guile manual for
the specifics on how to do this.

> Can someone can start me off on the right foot?

  Give the manual -- especially the descriptions of Scheme
programming, if you're not a functional-programming kind of person --
a thorough going-over, even though certain parts of it are out of date
or incomplete.  I should mention that I'm not exactly a Guile expert. 
Other people on this list may have better ideas.


Cheers,
Julian


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: Newbie - desigining apps

[Anthony Kozar]

IHDTM (I haven't done this myself), but based on knowledge of how scriptable
applications are often implemented on other platforms, I would suggest using
the Model-View-Controller pattern/paradigm.  Basically, you strive for a
clean separation between your data objects, the objects that display the
data, and the mechanisms/interface objects that allow those objects to be
manipulated.  (Just do a seach online for MVC to learn more).

This approach definitely requires designing your app from the beginning with
this separation in mind.  But the benefits of this design will I think be
useful in the future if you decide to add other controllers, views, etc.

In your case, I would guess that you will start off with two sets of
controllers for the same data -- one for your GUI and one for Guile.


Anthony Kozar
anthony.kozar@utoledo.edu
http://akozar.spymac.net/

On 10/7/04 9:12 PM, Max Polk<ux9i003@triad.rr.com> etched in stone:

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



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: Newbie - desigining apps

[Neil Jerram]

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