[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Chicken-hackers] [PATCH] adding support for letrec*
From: |
Felix |
Subject: |
Re: [Chicken-hackers] [PATCH] adding support for letrec* |
Date: |
Sat, 03 Aug 2013 15:11:45 +0200 (CEST) |
>> The attached patch adds support for "letrec*".
>
> Thanks a lot!
You're welcome.
>> - It is possible to detect access to uninitialized letrec as required
>> in R6RS (but not in R7RS) and done in a few R5RS Schemes
>> (e.g. Scheme48). This has an acceptable cost in interpreted code but
>> may be too expensive for compiled code.
>
> Here's a thought: could it be done by putting an annotation in the
> variable's plist in WALK, when processing ##core#letrec? It could list
> the preceding variables of the same letrec (those it shouldn't referr to).
> Then the scrutinizer might be able to give off a warning (or error)
> once it sees the value is coming from a preceding letrec-binding.
The scrutinizer is complex enough at it is, adding support for tracking
the binding forms will not make things better, I think.
>
> Doing it at runtime sounds trickier.
It's actually not that hard: initialize the variables with a unique
value and do a runtime-check at every reference.
> This happens in Scheme48:
>
>> (let ((a 1)) (letrec ((a 2) (b a)) b))
> Error: LETREC variable used before its value has been produced
>
> If letrec really is to let like letrec* is to let*, then it should
> see the outer a, I think. However, the spec explicitly says its
> an error, so I think we should try to emulate this behaviour as well.
No, the letrec introduces a and b, and the value part of the binding
is executed in a scope where a and b refer to the freshly introduced
variables - it wouldn't be letrec if it were otherwise.
> Same here. I've pushed this code, and we'll see what Salmonella
> says in the daily diff.
Thanks.