chicken-users
[Top][All Lists]
Advanced

[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



reply via email to

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