This is the mail archive of the guile@cygnus.com mailing list for the guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: non-hobbitable code


>>>>> "Klaus" == Klaus Schilling <Klaus.Schilling@home.ivm.de> writes:

    Klaus> now I installed hob-1.3.2, and thanks to B. Urban's
    Klaus> efforts, the libtool problems disappeared.

    Klaus> I found that some of the files I tried can not be
    Klaus> hobbitted.

    Klaus> One of them is the interface.scm that appears in Mike
    Klaus> Livshi's Pint, an interface-based object system for guile.

    Klaus> Another example is M. Stachowiak's optargs.scm (which is
    Klaus> part of the SCWM).

    Klaus> They both have in common that they use notations like #: or
    Klaus> #&, and hobbit breaks down when encountering those, with a
    Klaus> message about a read error/unknown kind of object. That's a

Hobbit currently only compiles R4RS (with some rare expections
involving mutual tail recursion and force).

    Klaus> pity because uncompiled pint is very slow (on my 8MB
    Klaus> snail).  Will that stuff get worked on in future?

In the near future, no. I think that an optimized hobbit targeted to
R4RS will be more useful than a catch-all compiler.

I would recommend to split an application to be compiled in
2 parts:
1) a compilable R4RS part (with defmacros)
2) an interpreted part with all bells and whistles specific to Guile

    Klaus> Independent from that, stuff like (define-public (func
    Klaus> . args) ...)  breaks with hobit, but this can be avoided by
    Klaus> (define-public func) (define (func args) ...), so no big
    Klaus> loss.

Have you a concrete example of this to send?

--

B. Urban