[Top][All Lists]
[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
- [Chicken-users] on the hardship of upgrading chicken from 4.6.1 to 4.6.3,
F. Wittenberger <=