--- TSa <[EMAIL PROTECTED]> wrote:
> I must admit that I hardly follow that statement. Why are
> 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.
> then a heavy re-assignment of semantics to things like '$x = $y'
> would become a symmetric assertion instead of asymmetric, imperative
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.
> 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.
> 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/