chicken-users
[Top][All Lists]
Advanced

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

[Chicken-users] on the hardship of upgrading chicken from 4.6.1 to 4.6.3


From: F. Wittenberger
Subject: [Chicken-users] on the hardship of upgrading chicken from 4.6.1 to 4.6.3
Date: Wed, 17 Nov 2010 21:59:35 +0100

== Summary ==

That's hard.

;-) WHY ;-)

* The handling of -extend has changed in a way I do not yet completely
understand.  Before I could define some syntax there and it would be
available during the compile.  Apparently that's no longer the case.
Now, since I used several different ways to convince chicken to compile
some modified syntax, I'm not yet sure in which cases it will work, and
which will break now.

Intentionally?

* I have a piece of code (which could be expressed in a much more modern
form, considering that there's a srfi-39 now) -- but the possible
improvement is not my point.  It better would still work, but it raises
a strange error right now and I have a work around, which is even more
strange (in a way, though I guess this hints towards an optimisation
error or alike):

Module A exports (just) 'root-object' (from these 3):

(define *root* #f)

(define (load-root . arg)
  (and-let* ((f (if (pair? arg) (car arg) (load-object  ... ... ...))))
            (set! *root* (object-identifier f))
            (object-identifier f)))

(define (root-object . x) (or *root* (apply load-root x)))

Module B (importing A) calls (root-object)

(root-object)  =>  #f

after a while:

(root-object)  =>  #<lambda info (A#root-object . x6617)>

The workaround so far: call ((identity root-object)) instead of
(root-object).

Hm.

Since the code structure in here is more or less a common idiom where
parameter objects are no choice for any reason, I'm unsurprised that
other pieces fail too.


Compiler options I used:
 -local -optimize-leaf-routines -inline -scrutinize -lambda-lift

best regards
/Jörg




reply via email to

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