Re: [Chicken-users] handling the undefined value

[Felix]

From: Jörg "F. Wittenberger" <address@hidden>
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