guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Planning work


From: Neil Jerram
Subject: Re: Planning work
Date: 28 Apr 2001 10:12:18 +0100
User-agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7

>>>>> "Thomas" == Thomas Bushnell, BSG <address@hidden> writes:

    Thomas> I'm going to be working for the FSF this summer on guile
    Thomas> translation agents.  That is, the long-wanted translators
    Thomas> for other languages into guile.

Good news.  There is a translation framework proposal written by
Mikael Djurfeldt that you might like to read through.  It's in the
guile-core/devel/translation directory in Guile CVS.

    Thomas> First, there is some kind of parser generator for guile,
    Thomas> right?

Not quite, no.  This is a subject that comes up quite frequently on
the mailing list, and various people say that they have various bits
of the solution, and it has never quite coalesced into a working and
available thing.

    Thomas> Second, is Python a good choice?  Is there any guile-ish
    Thomas> discussion about the task that would save me duplication
    Thomas> of thought or effort?

There has been some discussion about Python translation on the mailing
list over the last year or so - so check out the archive.  As far as I
recall those discussions, I think that Python would be a good choice,
since (i) it has a clean syntax (unlike e.g. Perl) (ii) it's widely
used (iii) it's sufficiently different from Scheme (unlike e.g. Emacs
Lisp) that we probably won't accidentally underdesign the translation
framework.

    Thomas> Third, where can I find documentation (however scanty) on
    Thomas> the guile module system?

Well, as Rob said, check the Guile Reference manual, but note that the
CVS version of this manual is much improved over any released
version.  Unfortunately, the improvement doesn't yet apply to the
section on the module system.

In addition to what Rob said, there are a number of options that you
can specify on the (define-modules ...) declaration:

  #:export (NAME ...)    ; alternative to saying (export NAME) for
                         ; each name in the code

  #:export-syntax (NAME ...)   ; similarly

  #:pure                 ; declare that module has no standard
                         ; bindings in it at all; hence useful,
                         ; but only if followed by ...

  #:use-module MODULE    ; alternative to saying (use-modules MODULE)
                         ; in the code

A good way to see how these declarations work is just to look at the
modules in the ice-9 directory in CVS.

Finally, note that the details of the module system are not set in
stone (although back compatibility is a requirement).  I believe it is
generally accepted that the module system and translation framework
are related, and that module system changes may be required to
accommodate translation.

        Neil




reply via email to

[Prev in Thread] Current Thread [Next in Thread]