--- 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.
> then a heavy re-assignment of semantics to things like '$x = $y'
> 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.


 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/

Reply via email to