HaloO, Ovid wrote:
In other words, I think we could get proper constraint programming if a subset can mutate its variable. Otherwise, all assignment would need to be wrapped inside of an eval and the code would be more bug-prone.
I must admit that I hardly follow that statement. Why are side-effects essential to achieve constraint programming and why do you think that the way to get at the constraint programming paradigm are the subset type definitions? E.g. to get constraint programming as I know it from Oz, Perl 6 would need a single assignment store first of all. And then a heavy re-assignment of semantics to things like '$x = $y' which would become a symmetric assertion instead of asymmetric, imperative assignment.
Will said mutating work? If it does, all logic handling constraints can be encapsulated in one spot. On the other hand, this could lead to mysterious action at a distance. The losses are significant, but the wins seem absolutely fascinating.
Could you give some hints on these fascinating wins, please. I for my part would argue the where blocks to be a very constraint form of block that generally has type :(Object --> Bool) and doesn't alter the object of concern in any way. Note that the where blocks are executed from within the type-checker or the dispatcher where no assumptions of the call environment other then the object should be made. Regards, TSa. -- "The unavoidable price of reliability is simplicity" -- C.A.R. Hoare "Simplicity does not precede complexity, but follows it." -- A.J. Perlis 1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan
