From: Jörg "F. Wittenberger" <[email protected]> Subject: [Chicken-users] handling the undefined value Date: Wed, 17 Nov 2010 20:56:29 +0100
>* 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? Of course. It is my secret plan to make things hard for you. So far you've done well, but I still have some mean tricks up my sleeve ... >* 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) =3D> #f >after a while: >(root-object) =3D> #<lambda info (A#root-object . x6617)> Very strange indeed. What is the value of *root* in this case? Do you use unsafe operations or low-level operations or the FFI for `load-object' or `object-identifier'? cheers, felix _______________________________________________ Chicken-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/chicken-users
