>> 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. _______________________________________________ Chicken-hackers mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/chicken-hackers
