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] |
>>>>> "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