[Top][All Lists]
[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.
- [Chicken-users] handling the undefined value, F. Wittenberger, 2010/11/17
- Re: [Chicken-users] handling the undefined value, Felix, 2010/11/17
- Re: [Chicken-users] handling the undefined value, Felix, 2010/11/17
- Re: [Chicken-users] handling the undefined value,
F. Wittenberger <=
- Re: [Chicken-users] handling the undefined value, Felix, 2010/11/19
- Re: [Chicken-users] handling the undefined value, F. Wittenberger, 2010/11/19
- Re: [Chicken-users] handling the undefined value, Felix, 2010/11/20
- [Chicken-users] NE [[not exactly]]: handling the undefined value, F. Wittenberger, 2010/11/21
- [Chicken-users] Re: NE [[not exactly]]: handling the undefined value, Felix, 2010/11/22
- Re: [Chicken-users] handling the undefined value, F. Wittenberger, 2010/11/22
- Re: [Chicken-users] handling the undefined value, Felix, 2010/11/24
- Re: [Chicken-users] handling the undefined value, John Cowan, 2010/11/24
- Re: [Chicken-users] handling the undefined value, F. Wittenberger, 2010/11/25
- Re: [Chicken-users] handling the undefined value, Felix, 2010/11/25