chicken-hackers
[Top][All Lists]
Advanced

[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.



reply via email to

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