From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Neil Jerram Newsgroups: gmane.lisp.guile.user Subject: Re: language translator help Date: 28 Apr 2002 19:21:51 +0100 Sender: guile-user-admin@gnu.org Message-ID: References: <15561.38014.967466.255795@segfault.bogus.domain> <15563.18078.788420.299836@segfault.bogus.domain> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1020018502 14066 127.0.0.1 (28 Apr 2002 18:28:22 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 28 Apr 2002 18:28:22 +0000 (UTC) Cc: guile-user Return-path: Original-Received: from fencepost.gnu.org ([199.232.76.164]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 171tPJ-0003eS-00 for ; Sun, 28 Apr 2002 20:28:21 +0200 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 171tOO-0004JG-00; Sun, 28 Apr 2002 14:27:24 -0400 Original-Received: from mail.uklinux.net ([80.84.72.21] helo=s1.uklinux.net) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 171tNi-0004Fx-00 for ; Sun, 28 Apr 2002 14:26:43 -0400 Original-Received: from portalet.ossau.uklinux.net (dial-212-159-134-177.access.uk.tiscali.com [212.159.134.177]) by s1.uklinux.net (8.11.6/8.11.6) with ESMTP id g3SIQck20870; Sun, 28 Apr 2002 19:26:38 +0100 Original-Received: from laruns.ossau.uklinux.net.ossau.uklinux.net (laruns.ossau.uklinux.net [192.168.1.3]) by portalet.ossau.uklinux.net (8.11.3/8.11.3/SuSE Linux 8.11.1-0.5) with ESMTP id g3SJPx807293; Sun, 28 Apr 2002 19:25:59 GMT Original-To: "John W. Eaton" Original-Lines: 113 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 Errors-To: guile-user-admin@gnu.org X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.0.9 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.lisp.guile.user:354 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.user:354 >>>>> "John" == John W Eaton writes: John> On 27-Apr-2002, Neil Jerram wrote: John> | If Elisp is a guide [...] John> I think it performance might be better in most cases because Octave's John> interpreter is known to be really slow for many operations. OK, let's hope so. John> | - You have to believe that implementing your language constructs in John> | Scheme is easier to maintain than implementing them in C. John> Well, I'm not sure. But it is a lot of work to write an maintain an John> interperter for a special language, and much of that effort is John> duplicated by every scripting language. People using Octave and Guile John> both want access to OS system calls and library functions (from basic John> stuff to GUI toolkits) so it seems wasteful to me that we build many John> interfaces to all these different libraries. I think it would be much John> better to take advantage of existing work that's already been done. Agreed - there is duplication that can be removed, and it will be cool to have, e.g., a gnuplot interface available in Guile in general. But I think the point about Scheme vs. C is still important. If your language has a `for' construct, you have to implement it somehow, unless you are lucky enough that the target language already has an identical construct. IMO, Scheme is easier for this than C in individual cases (e.g. compare unwind-protect in CVS guile-core/lang/elisp/primitives/syntax.scm and in the Emacs source eval.c). And, where there is a pattern in the way that a group of constructs maps from your language to the target, Scheme has more ways than C of allowing you to express that pattern in your construct definitions. John> | [...] might end up wanting to John> | keep it in C anyway (but switch to using Guile data types). John> Along with a way to call Guile functions, this would offer a lot, but John> I would still like to get away from having to maintain the low-level John> details of an interpreter. Agreed. The low-level details I can think of that Guile could handle for you are: - memory allocation and GC - evaluation, function and macro dispatching - having to have a representation for the code that you have read in - bignums, if Guile's bignum meet Octave's existing needs - other basic data types like numbers and strings - arrays, if you think that Guile's uniform array implementation is suitable. Any others? John> | Right, but this is just a matter of wrapping existing code, isn't it? John> Yes and no. There is the opportunity to correct some of the mistakes John> of the past too, which might mean more than just wrapping the current John> Octave classes. OK. John> | John> [...] having the translator is essential. John> | John> | Totally agree; this is what Guile is supposed to be about: providing John> | language flexibility to its users. John> Yes, but there seem to be no fully functional examples of actually John> doing this yet. If that's correct, why not? What's keeping people John> from doing this? John> One problem that I can imagine is that for languages like Perl, or John> Python, which are starting to be quite large, it's not enough to just John> translate the syntax to scheme, you need the run-time. Integrating John> all of that could be a lot of work. But I think that a bigger problem John> is that there is no standard for these languages, so the language John> definition is whatever the real Perl or Python interpreters do today. John> Unless the authors of those tools integrate the Guile interpreter in John> their own code, the fork becomes difficult to maintain. John> These sorts of problems would not cause trouble for Octave, because I John> would be integrating Guile completely. I'm just trying to understand John> what might be the reasons that we don't have many translators. This is my analysis too. In the Elisp case, FWIW, it's certainly true that you need the runtime to have a useful system, and that the best way to get (most of) it is to build the Emacs source in a modified form. This is what Ken Raeburn's Guile-based Emacs project is doing. Therefore, it's a codebase management issue (or, equivalently, a not-wanting-to-fork issue). Tracking a separately managed project is already very hard even if your aim is only to copy its syntax and semantics. When you want to reuse a lot of that project's source code as well, but in a modified form, but also stay in sync as new releases come out, it gets harder. Cf. Ken's project, which was put back some way by Emacs 21 coming out. Ideally, serious political will is needed on the part of the project that you are trying to track. (Note that this does not exist in the Emacs case, AFAIK.) Barring that, I imagine it helps if the target is standardized or changing very slowly. My guess is that writing a good translator without full Guile integration may prove impossible. But perhaps Thomas Bushnell's Python will provide a counter-example - I hope so. Neil _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://mail.gnu.org/mailman/listinfo/guile-user