Posted: Thu Apr 24, 2008 2:23 am
Invertible z
One application is 3-D, e.g. some objects have inside/outside relationships to some centre, and you want to show this in profile, with outwards extending both directions along z.
More generally though, (CF is not about representational depiction) I suspect there are some cunning and attractive effects to made with reversible stacking.
Useable iterator values
I believe that cumulative adjustments are always ignored on the first pass, so zero-indexing has a natural sense to it.
The kind of variable reference I'd go for is like "$1" for the innermost, "$2" for the one outside that. This has the advantage of keeping inner loop code independent of whether it appears inside another loop, and being naturally extensible to deeper nesting, should that ever be considered.
(I don't know about "$0". I feel that it should be reserved for something special, but I don't know what)
Also going back a bit, I don't see why named constants should have anything to do with parameterization.
The main impetus behind constants is reliable code maintainence and modification. All that is needed is string substitution during parsing; it has no effect on rule interpretation.
Script arguments can be handled the same way, without rule parameterization.
The reason I mention this is that I have reservations about rule parameterization. I'm still not sure that I have an objection worth making, but I feel that I should make my ambivalence known.
One application is 3-D, e.g. some objects have inside/outside relationships to some centre, and you want to show this in profile, with outwards extending both directions along z.
More generally though, (CF is not about representational depiction) I suspect there are some cunning and attractive effects to made with reversible stacking.
Useable iterator values
I believe that cumulative adjustments are always ignored on the first pass, so zero-indexing has a natural sense to it.
The kind of variable reference I'd go for is like "$1" for the innermost, "$2" for the one outside that. This has the advantage of keeping inner loop code independent of whether it appears inside another loop, and being naturally extensible to deeper nesting, should that ever be considered.
(I don't know about "$0". I feel that it should be reserved for something special, but I don't know what)
Also going back a bit, I don't see why named constants should have anything to do with parameterization.
The main impetus behind constants is reliable code maintainence and modification. All that is needed is string substitution during parsing; it has no effect on rule interpretation.
Script arguments can be handled the same way, without rule parameterization.
The reason I mention this is that I have reservations about rule parameterization. I'm still not sure that I have an objection worth making, but I feel that I should make my ambivalence known.