On Sun, May 8, 2011 at 05:01, Daniel V. Klein <d...@lonewolf.com> wrote:
> But yes, it would have been difficult to define YrMod3Eq2, because then you > have to work very hard to make everyone happy, and eventually someone starts > insisting on getting real math, and then the whole promise theory > implementation breaks, because you can't effectively mix procedural code > with declarative code :-) Oh, I had considered the technical aspect, but of course there's *that* part as well. :) However, I was only suggesting those basic hard-coded classes -- the "Mod" in there doesn't mean "do the modulus and compare", but rather "the result of the modulus is equal to". A subtle difference but an important one -- in the former case, it's imperative, but in the latter it's declarative and you'd be able to determine the classes before-hand if there is a finite set of choices. That's why I suggested a constant maximum for the mod classes, that could be changed at compile-time but not thereafter. Also, you can already do "real math" -- call a shell command to do the computation and use an appropriate return code, then define the class based on that. If the command is pure (as in "pure function") then it fits in with promise theory. Anyhow, this seems like a very academic discussion (which I am absolutely happy to have!) -- I don't see a practical use, for myself, for the life-cycle classes. -- Jerome Baum tel +49-1578-8434336 email jer...@jeromebaum.com -- PGP: A0E4 B2D4 94E6 20EE 85BA E45B 63E4 2BD8 C58C 753A PGP: 2C23 EBFF DF1A 840D 2351 F5F5 F25B A03F 2152 36DA
_______________________________________________ Help-cfengine mailing list Help-cfengine@cfengine.org https://cfengine.org/mailman/listinfo/help-cfengine
