From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Vorfeed Canal Newsgroups: gmane.lisp.guile.user Subject: Re: PHP to GUILE Date: Tue, 27 Sep 2005 14:11:47 +0400 Message-ID: <6efab235050927031160fe348a@mail.gmail.com> References: <6efab235050925145055ba774c@mail.gmail.com> <87ll1k61w4.fsf@zip.com.au> <6efab235050926004326d03d6a@mail.gmail.com> <6efab23505092609331abd82b7@mail.gmail.com> <6efab2350509260934639fcc59@mail.gmail.com> Reply-To: Vorfeed Canal NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: sea.gmane.org 1127817159 6167 80.91.229.2 (27 Sep 2005 10:32:39 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 27 Sep 2005 10:32:39 +0000 (UTC) Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Tue Sep 27 12:32:36 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1EKCjL-0002bw-OK for guile-user@m.gmane.org; Tue, 27 Sep 2005 12:30:37 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EKCjF-0005Nj-7t for guile-user@m.gmane.org; Tue, 27 Sep 2005 06:30:30 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1EKCY9-0001OW-55 for guile-user@gnu.org; Tue, 27 Sep 2005 06:19:01 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1EKCY3-0001Lj-Ob for guile-user@gnu.org; Tue, 27 Sep 2005 06:18:58 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EKCY3-0000xP-23 for guile-user@gnu.org; Tue, 27 Sep 2005 06:18:55 -0400 Original-Received: from [72.14.204.199] (helo=qproxy.gmail.com) by monty-python.gnu.org with esmtp (Exim 4.34) id 1EKCRC-0002vX-T8 for guile-user@gnu.org; Tue, 27 Sep 2005 06:11:52 -0400 Original-Received: by qproxy.gmail.com with SMTP id e14so261452qbc for ; Tue, 27 Sep 2005 03:11:47 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=A3FyNjvRMzzGSu3Di4mqJ4pHwccEeNhf0FIMT2Dbu87U+7/k0i/bD2PTX0ZXWMCevbQc0FHR+9ULnm/Xp1rzGJavhiPGWaDXFGYGEFXBianvNPm3mwxEYRPc+cSNM9tCHBi9E+1c1lv+LSeofxYj8SGkQYt6TJ/hgCR79ZPmsPk= Original-Received: by 10.65.123.7 with SMTP id a7mr232541qbn; Tue, 27 Sep 2005 03:11:47 -0700 (PDT) Original-Received: by 10.65.100.16 with HTTP; Tue, 27 Sep 2005 03:11:47 -0700 (PDT) Original-To: guile-user@gnu.org In-Reply-To: Content-Disposition: inline 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:4786 Archived-At: On 9/27/05, Thien-Thi Nguyen wrote: > > Hmm... And why "module catalogs" are superior ? I see one reason for > their existence, but may be there are ones. For example I view this > feature: "the actual placement of the file in the filesystem is > decoupled from its module name" as DISadvantage... I mean: we need > hierarchy of modules, we have perfect system to organize objects in > hierarchy called "filesystem" why we'll ever want to replace it > without very compelling reasons? > > i think module catalogs are superior because they address some of your > concerns (which i recognize since similar thinking inspired the design > and implementation of the module catalog system). > I *DO* comprehend the need for something like this "in the bright future" (after all translators must allow guile to use modules written in list or TCL). But today... for just two possibilities (C glue code and scheme sources) they look like much and too little in the same time. Too much: we have two distinct things - stand-alone scheme modules and non-stand-alone C glue code (:autoload is deprecated, rememeber?). Plus C glue code is architecture-dependent (thus must be in /usr/lib somewhere) while scheme code is not (so it must go in /usr/share somewhere). Too little: there are no supports for translators anyway (or I'm wrong and it IS possible to write module in Logo?). So I think for today simple search over two distinct lists (one for architecture-dependent glue code and one for architecture-independent scheme modules) are the best solution. Later when we'll have translators and everything may be module catalogs will be usefull, but not today. > perhaps you are not aware that module catalogs map module names (list of > symbols like: (ice-9 q)) to module implementations, which are actually > files in the filesystem? I *AM* aware. But I think that modules catalogs are overkill for what is awailable today and not enough for what is really needed in the future. Thus it's better to use simpler approach: less complexity and more-or-less the same benefits. Once we'll have loadable translators and everything related we'll need some more complex approach. > the particular implementations supported are currently scheme code and sh= ared object > libraries, the latter thanks to libtool support in runtime and methodolog= y. > And scheme code and shared object libraries are different enough to make lumping them together rather impractical, while list and TCL are not supported anyway - so what's the point ? > iirc, in an earlier message you ask for user ability to specify things > (at runtime). the decoupling mentioned is a clean way to effect that. > I just want a way to keep all files related to some-big-project in /usr/{lib,share}/same-big-project (unlike mess xchat-guile) and all files related to guile x.y.z in /usr/{lib,share}/guile-something - that's all. I do not think it's good idea to change the path on the fly too often - more like part of initial setup + small extra (for emergencies). > i will augment the docs to emphasize that the module catalog system does > not replace guile's historic resolution process (the end result of which > is always some file on the filesystem), but simply formalizes it (a bit) > and extends it (a bit) in a backward- and (i hope) upward-compatible > way. thanks for showing me how the docs can cause misunderstanding. > To be frank the main part of doc is not even module system specification and/or something like this but answer on simple question WHY?. Why guile 1.4.1.1xx was ever developed ? Why parts of it are not included in later versions of guile (yes, I know it's unofficial - yet GNU Emacs does include some reimplemented extensions from XEmacs, so it's not THE reason). I was unable to find this in documentation (or better yet on site) so I was sure guile 1.4.1.106 is just bugfix release for modern compilers. > The biggest problem with this mechanism is that it's unsupported by > official version. > > if i can fix the problem of not having write privs, i can fix this > problem as well (but not having write privs is no longer my problem). It's my problem, right. Since guile 1.4 does not support some features I want/need (GOOPS and pthreads are major ones) I can not use nice things from your 1.4.1.1xx releases. _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://lists.gnu.org/mailman/listinfo/guile-user