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: Thu, 18 Nov 2010 22:42:42 +0100

Am Mittwoch, den 17.11.2010, 23:59 +0100 schrieb 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)  =>  #f
> 
> >after a while:
> 
> >(root-object)  =>  #<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'?

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.

Strange to see how the garbage looks alike once I made a mess out of my
code.




reply via email to

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