On Mon, Dec 28, 2015 at 09:32:24AM +0100, Sven Hartrumpf wrote: > PB wrote on 2015-12-24 11:25: > > These features are a bit weird: when you require a core library, it will > > register a feature with the same name (I think that's to prevent it from > > being reloaded again). I'm not sure if this is in general for units or > > only for core units, but I think the problem here is that the compiler > > loads all of them. So you're really cond-expanding against what's > > been loaded by the compiler, which is of course undocumented and subject > > to change. > > And hopefully is changed ... in chicken 5? :-)
There are plans to overhaul the whole unit/module/library loading stuff, but development on CHICKEN 5 seems to have stalled a bit. We need more people to work on it, even if just to flesh out the desired API. > >> Example: > >> > echo "(cond-expand (srfi-1 (print "srfi-1")) (else))" > bugchicken2.scm > >> > csi -e '(load "bugchicken2.scm")' > >> > -> as expected > >> > csc bugchicken2.scm && ./bugchicken2 > >> srfi-1 -> unexpected; csc should behave like csi. > > > > If you don't mind doing this at runtime, that's a solution: > > > > (when (feature? srfi-1:) (print "srfi-1")) > > Thanks for the idea. > But I need cond-expand mainly to write programs that are portable > across different Scheme implementation. So I cannot replace the > most basic SRFI-0 by some implementation-specific variant. You could still do something like (cond-expand (chicken (when (feature? srfi-1:) (print "srfi-1"))) (gauche ...) (chibi ...) (else ...)) It's not pretty but it should do the trick. You could even write a macro that expands to the desired cond-expand form, but that's a bit tricky to do if you can't rely on syntax-rules being present. Cheers, Peter
signature.asc
Description: Digital signature
_______________________________________________ Chicken-users mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/chicken-users
