From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Julian Graham Newsgroups: gmane.lisp.guile.user Subject: Re: Newbie - desigining apps Date: Thu, 7 Oct 2004 22:49:04 -0400 Sender: guile-user-bounces+guile-user=m.gmane.org@gnu.org Message-ID: <2bc5f82104100719495e954519@mail.gmail.com> References: <4165E98D.3090304@triad.rr.com> Reply-To: Julian Graham NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1097203785 7570 80.91.229.6 (8 Oct 2004 02:49:45 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 8 Oct 2004 02:49:45 +0000 (UTC) Cc: Guile User Mailing List Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Fri Oct 08 04:49:33 2004 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1CFkp2-0003IC-00 for ; Fri, 08 Oct 2004 04:49:32 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CFkvn-0005wc-QW for guile-user@m.gmane.org; Thu, 07 Oct 2004 22:56:31 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1CFkvk-0005wM-Am for guile-user@gnu.org; Thu, 07 Oct 2004 22:56:28 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1CFkvj-0005wA-TR for guile-user@gnu.org; Thu, 07 Oct 2004 22:56:28 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CFkvj-0005w7-KH for guile-user@gnu.org; Thu, 07 Oct 2004 22:56:27 -0400 Original-Received: from [64.233.170.195] (helo=mproxy.gmail.com) by monty-python.gnu.org with esmtp (Exim 4.34) id 1CFkob-0004dE-39 for guile-user@gnu.org; Thu, 07 Oct 2004 22:49:05 -0400 Original-Received: by mproxy.gmail.com with SMTP id 74so1029185rnl for ; Thu, 07 Oct 2004 19:49:04 -0700 (PDT) Original-Received: by 10.38.165.18 with SMTP id n18mr2941506rne; Thu, 07 Oct 2004 19:49:04 -0700 (PDT) Original-Received: by 10.38.208.5 with HTTP; Thu, 7 Oct 2004 19:49:04 -0700 (PDT) Original-To: Max Polk In-Reply-To: <4165E98D.3090304@triad.rr.com> X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Xref: main.gmane.org gmane.lisp.guile.user:3530 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.user:3530 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