--- TSa <[EMAIL PROTECTED]> wrote: > 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?
Because I can't think of any other way to do it :) > 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. Now it's my turn to say that I can't follow that statement. > Could you give some hints on these fascinating wins, please. I explain in more detail at http://use.perl.org/~Ovid/journal/36667 You asked why I think that constraints would need to modify the variable (would "invocant" be the right term here?). In logic programming, constraints merely help prune search tress to a reasonable amount. Nothing is mutated (as far as I'm aware). In imperative or OO code, I would think that a constraint *must* be mutating or else you have little more than DBC (design by contract). Am I missing something fundamental here? Examples welcome. Cheers, Ovid 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 > -- Buy the book - http://www.oreilly.com/catalog/perlhks/ Personal blog - http://publius-ovidius.livejournal.com/ Tech blog - http://use.perl.org/~Ovid/journal/
