[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Chicken-users] How to avoid predefined cond-expand features in csc?
From: |
Sven Hartrumpf |
Subject: |
Re: [Chicken-users] How to avoid predefined cond-expand features in csc? |
Date: |
Mon, 28 Dec 2015 09:32:24 +0100 (CET) |
Hi Peter.
PB wrote on 2015-12-24 11:25:
> On Thu, Dec 24, 2015 at 11:10:40AM +0100, Sven Hartrumpf wrote:
>> Hi.
>>
>> csc seems to predefine some cond-expand feature (srfi-1, srfi-13, srfi-14,
>> srfi-69, maybe more) for the program to be compiled. How to prevent this?
>
> 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? :-)
>> 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.
Ciao
Sven