chicken-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-users] handling the undefined value


From: F. Wittenberger
Subject: Re: [Chicken-users] handling the undefined value
Date: Fri, 19 Nov 2010 22:31:29 +0100

Am Freitag, den 19.11.2010, 02:56 -0500 schrieb Felix:
> From: Jörg "F. Wittenberger" <address@hidden>
> Subject: Re: [Chicken-users] handling the undefined value
> Date: Thu, 18 Nov 2010 22:42:42 +0100
> 
> > 
> > I guess I found the reason: "-local".  Apparently it changed slightly.
> > 
> > At least I found a case, where one compilation unit of mine used set! to
> > change the value of root-object.  Once removed the error is gone (though
> > now I have a lot of trouble with the program logic ;-).
> > 
> > I did not catch that before, because the -local switch is there for
> > quite a long time.
> > 
> 
> Yes, local mode is used more aggressively recently. It implies that
> toplevel definitions inside the compilation unit are not modified from
> outside (other compilation units or evaluated code). This gives much
> more inlining opportunities (which, in turn, gives most performance
> improvements). Unfortunately, redefinitions or modifications of such
> toplevel variables from other compilation units will be ineffective,
> thus not following R5RS semantics. Therefore either do not compile
> in local mode (implied by optimization-level 3), or use
> 
>   (declare (not inline <IDENTIFIER>))
> 
> which will prevent <IDENTIFIER> from being inlined (either completely,
> or by replacing its invocation with a direct call).

THANK YOU VERY MUCH

;-)

Seriously: I know that there is a Turing complete way to modify either
the Scheme source, auxiliary input or the compile time switches of
chicken to make it compile any address@hidden data sample into a standard
"Hello world".

But when I put "-local" into the Makefile I thereby want to express that
I do not expect my source to violate the documented rules wrt. "-local".

It's a different questions whether or not that's a) being completely
ignored b) results in garbage c) gives decent, decorated error messages
if violated.  (In order of my personal preference.)  In this case it's
(b) - second to best.

/Jörg

PS: I *love* to learn that way, that -local is more better than (a) than
before.  ;-)




reply via email to

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