From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Neil Jerram Newsgroups: gmane.lisp.guile.user Subject: Re: Module unloading Date: Thu, 26 May 2005 19:25:51 +0100 Message-ID: <429614AF.8000908@ossau.uklinux.net> References: <38294b74050523070378b75caf@mail.gmail.com> <42921E8E.7060503@ossau.uklinux.net> <38294b74050523135563afe3dc@mail.gmail.com> <429249E3.1050604@ossau.uklinux.net> <38294b7405052406021c0ec40f@mail.gmail.com> <42936F3C.3090409@ossau.uklinux.net> <38294b7405052414062801ceba@mail.gmail.com> <38294b7405052414266f95d20a@mail.gmail.com> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1117132189 8908 80.91.229.2 (26 May 2005 18:29:49 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 26 May 2005 18:29:49 +0000 (UTC) Cc: guile-user@gnu.org Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Thu May 26 20:29:47 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1DbN5d-0003Mi-1z for guile-user@m.gmane.org; Thu, 26 May 2005 20:28:17 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DbN9k-0001ED-6A for guile-user@m.gmane.org; Thu, 26 May 2005 14:32:32 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1DbN9U-00018F-WB for guile-user@gnu.org; Thu, 26 May 2005 14:32:17 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1DbN9S-00015Y-0d for guile-user@gnu.org; Thu, 26 May 2005 14:32:15 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DbN9R-00012W-4q for guile-user@gnu.org; Thu, 26 May 2005 14:32:13 -0400 Original-Received: from [80.84.72.33] (helo=mail3.uklinux.net) by monty-python.gnu.org with esmtp (Exim 4.34) id 1DbN42-00082a-24 for guile-user@gnu.org; Thu, 26 May 2005 14:26:40 -0400 Original-Received: from laruns (host81-130-111-97.in-addr.btopenworld.com [81.130.111.97]) by mail3.uklinux.net (Postfix) with ESMTP id BDE4A409FB6; Thu, 26 May 2005 18:25:53 +0000 (UTC) Original-Received: from [127.0.0.1] (laruns [127.0.0.1]) by laruns (Postfix) with ESMTP id 163F76F784; Thu, 26 May 2005 19:25:52 +0100 (BST) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050513 Debian/1.7.8-1 X-Accept-Language: en Original-To: Zeeshan Ali In-Reply-To: <38294b7405052414266f95d20a@mail.gmail.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: , Original-Sender: guile-user-bounces+guile-user=m.gmane.org@gnu.org Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.user:4590 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.user:4590 Zeeshan Ali wrote: > Hello again, > > >>> Why not use a registration >>>API instead? In other words, instead of this: >>> >>>(define (do-plugin-thing-1 ...) ...) >>>(define (do-plugin-thing-2 ...) ...) >>>... >>> >>>do this: >>> >>>(let () >>> (define (do-plugin-thing-1 ...) ...) >>> (define (do-plugin-thing-2 ...) ...) >>> ... >>> (register-plugin do-plugin-thing-1 >>> do-plugin-thing-2 >>> ...)) > > > This is the code of the plugin right? and register-plugin is a > function provided by me for the plugins to call? Yes, exactly. > But i'll still need > an entry point inside the plugin: a procedure that i'll call from the > module as soon as i load it. So this approach doesn't seem to be of a > big advantage. I'm not sure I understand. Do you need to call this procedure even before the plugin code calls register-plugin (which would happen automatically when the plugin code file is loaded)? It's difficult to see how there could be a requirement for this, given that it is impossible to separate the loading and the register-plugin call. If it is OK to call this procedure after register-plugin has been called, then the procedure to call could be another argument to register-plugin: (register-plugin init-proc do-plugin-thing-1 do-plugin-thing-2 ...)) > I think I have figured-out a way out of this visibility problem: > > (define amodule (resolve-module '(amodule))) > ((variable-ref (module-local-variable amodule 'xchat-plugin-init))) > > This code seems to work and there is no need for the plugin to > export it's objects anymore. Yes, this would be fine. >> Also, this way you could stay >> >>>pure-R5RS if you like, as you don't really need any features of the >>>module system. > > > Wait a sec? Are you really thinking what i think you are thinking: > use the simple 'load' procedure combined with your suggested > registeration API instead of using the module system of guile? Yes. It may indicate a deficiency in the module system, but I don't think that modules are currently especially well aligned with the requirements of acting as a plugin. In my view modules are mostly useful (and work very well) for organizing the code of a non-trivial application (and with a thought of identifying and grouping together the code that might be reusable by other applications). To map this onto your program, I think it would be absolutely fine to use just load to load plugins - in fact this would work well with a standard File Selector GUI: "Browse for plugin ...", whereas for a module-based invocation you'd need to invent a new dialog. Please note that, even when a file is loaded using plain "load": 1. The plugin author can still choose to make their file a module, if that is of use to them, by beginning it with a (define-module ...) form. 2. The plugin author can still choose to use modules to organize their plugin code internally, by splitting out some of the code into modules and using (use-modules ...) from the main file to load them. 3. The plugin author can still use third-party modules, using (use-modules ...). Regards, Neil _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://lists.gnu.org/mailman/listinfo/guile-user