CLP(FD): what is necessary?

Hi,
I am transferring a private discussion with Markus Triska
about clpfd library that is a part of SWI Prolog.
Markus asked me (after tracking my discussion on
polish newsgroup with AL) what is wrong with his clp library.
I will be talking only about ECLiPSe and SWI because
this two prologs are only that could be considered
as free.

From my point of view, clp(fd) library must be
extensible. By extensible I mean not only technical
possibilities to write their own global constraints
but also good manual (SWI lacks such manual). ECLiPSe
provides its users with quite good manual on creating
global constraints. Moreover good clp library should
have a wide range of global constraints. Good reference
is SICStus. Both ECLiPSe and SWI seems poor comparing to
SICStus.

In our discussion Markus suggested that
incorporating propia or CHR could be an answer for
the need of customized global contraints.
Propia is really interesting but for now it
is completely useless for me as my software should
run quickly. To achieve this I have to write special
global constraints from scratch. Any black-box approach
is not acceptable. This differs CLP from MIP by the way.

Regarding CHR I cannot say much as I have never
used this methodology. Nevertheless it looks quite
interesting.

Good environment for developing software that
is based on clp should provide its users with clean
and robust interface. By clean I mean mainly
clear syntax. Delay clauses
(http://eclipse.crosscoreop.com/doc/...umsroot111.html)
are good approach. In ECLiPSe there is also another
mechanism based on suspensions (Internally both
approaches are equivalent). The problem with
ECLiPSe is that it each suspension can have a
priority. This makes implementing constraints
really painful and makes ECLiPSe not robust.
I had not enough time to track in depth Markus' library.
My impression is that it is less cleaner that ECLiPSe's
suspension mechanism but it seems to be more robust
(no priorities!).

Very nice mechanism has B-Prolog. Also SICStus is
a good solution.

So going back to Markus' basic question: "How can
I improve clpfd library?". My answer is to:
1) write a documentation with examples :)
2) Create more clean syntax for defining constraints.
It is really important to have a clear syntax
from which a user could easily deduce conditions
that wakes the constraint. The conditions are:
- a variable has been instantiated
- a variable has been bounded (min or max)
- a variable's domain has been changed

In ECLiPSe you can use the following syntax
(such syntax is clean to me):

suspend(
propagator(X),
Priority,
[
X->inst, %instantiated variable
X->ic:min, %lower bound has been changed
X->constrained %a domain has been altered
]
)

In SICStus you would use:
fd_global(
propagator(X),
state(Y),
[
val(X),
min(X),
dom(X)
]
)

Developer having such code can very quickly
deduce the logic behind global constraint.
In this example propagator(X) is woken
if one of the following conditions occur:
- X has been instantiated
- lower bound of X has been changed
- X's domain has been changed

Mark, could you show us how you can do this in
SWI now?

2) develop global constraints that users could
use out-of-the-box.

3) do not try to pursuit ECLiPSe's propia or CHR.
Try to make as much as possible functionality
that SICStus' clp(fd) library offers.
It would have been MUCH better for ECLiPSe if developers
had implemented more global constraints
and not add new functionality (like propia).

4) Speed of execution is not always a matter. It is nice
to have fast prolog implementation but from my experience
the biggest speedup comes from specialised propagators
and not from specific implementation.

My opinion is that free prologs could be used for
proprietary software but their creators should
pay more attention to what is important to business
and business needs "just-enough" solutions and
not "do-everything" solutions.

Markus, I hope I have answered your questions.
I suppose that AL would drop his views on the
issue ;).

Best regards
--
[ Wit Jakuczun    <W.Jakuczun [at] wlogsolutions.com> ]
[ WLOG Solutions  http://www.wlogsolutions.com ]

On 2008-03-13, Wit Jakuczun <wit@mefisto.hades> wrote:
> Hi,
>    I am transferring a private discussion with Markus Triska
> about clpfd library that is a part of SWI Prolog.
>    Markus asked me (after tracking my discussion on
> polish newsgroup with AL) what is wrong with his clp library.
> I will be talking only about ECLiPSe and SWI because
> this two prologs are only that could be considered
> as free.

<snip>

Thanks for your input.  I'd like to concentrate on this:

> My opinion is that free prologs could be used for
> proprietary software but their creators should
> pay more attention to what is important to business
> and business needs "just-enough" solutions and
> not "do-everything" solutions.

I think the discussion is about `free'. As you can learn from the FSF
website, free isn't about free as in free beer, but in free as in
freedom of speech. That is the case here as well. I'm more inclined to
use `Open'. Not in the way you us it, although that form of openness is
important to reach my `Open': community carried software. If you want to
do commercial development with a free Prolog, you should become member
of its community and guide it in the direction you want, either by
investing time in development, testing, documenting, etc. or by
investing money to get someone else (sometimes the main developers,
sometimes another expert) do the work. Using that principle it works for
both sides. The developers get financial resources and code from the
community, the users gets direct access to developers and the rest of
the community and profits from the testing and extensions from other
parts of the community.

Done properly, this is highly effective for everybody because it greatly
reduces overhead costs. Just think or marketing, legal costs, trying to
establish and protect license schemas, financial and organizational
hassle buying and selling software, etc.

Note that it works for small and big communities and even comparable to
commercial software. Specialized commercial software is very expensive,
while in small open communities each member needs to invest majorly. Big
mainstream commercial software is cheap and in big mainstream open
projects you don't have to do much.

I think Markus is doing a great job establishing a clp(fd) library with
some nice features.  I'm sure he is interested in enhancing the design
and make it easy to extend.

Some things are almost inherently associated with community software.
Not that many developers like documenting and where documenting a single
piece of the cake is still doable, keeping the dependencies in the
overall documentation up to date is asking too much. Only big
communities can fix the documentation problem by regularly publishing
nice integrated documentation as a book.  Small communities have to work
with nice, largely automated, tools to get some minimal documentation.

Cheers --- Jan

On 13 Mar 2008 13:23:32 GMT, Jan Wielemaker <jan@nospam.ct.xs4all.nl>
wrote:

>On 2008-03-13, Wit Jakuczun <wit@mefisto.hades> wrote: 
>
><snip>
>
>Thanks for your input.  I'd like to concentrate on this:
> 
>
>I think the discussion is about `free'.

I see this discussion (at least, as it started on pl.comp.lang.c) a
bit differently: what is needed to have complete CLP(FD) system that
could be useb not only for solving MONEY and Sudoku problems, but
problems of industrial complexity ans scale.

One requirement, posted on that discssion was that there must be
framework for creating new global constraints. And this is what I
don't see in SWI CLP(FD) library. Or it is there, but I don't see
this?...

A.L.

Dnia 13 Mar 2008 13:23:32 GMT
Jan Wielemaker <jan@nospam.ct.xs4all.nl> napisa=C5=82(a):

> <snip>
>=20
> Thanks for your input.  I'd like to concentrate on this:
>=20 
>=20
> I think the discussion is about `free'.
No. The discussion is about improving clp(fd) library
in SWI (and other free prologs). I have presented my point=20
of view, that's all.

I would prefer not talking about FSF and their understanding
of freedom. I understand you point of view though.

> If you want to do commercial development with a free Prolog, you should=20
> become member of its community and guide it in the direction you want
My post is a such guidance.=20

> I think Markus is doing a great job establishing a clp(fd) library with
> some nice features.  I'm sure he is interested in enhancing the design
> and make it easy to extend.
>=20
Of course! I happily expressed my opinions to Markus.=20
I did not want to criticize Markus.

Best regards
--=20
[ Wit Jakuczun    <W.Jakuczun [at] wlogsolutions.com> ]
[ WLOG Solutions  http://www.wlogsolutions.com ]

Wit Jakuczun <wit@mefisto.hades> writes:
>   From my point of view, clp(fd) library must be
>extensible. By extensible I mean not only technical
>possibilities to write their own global constraints
>but also good manual (SWI lacks such manual). ECLiPSe
>provides its users with quite good manual on creating
>global constraints. Moreover good clp library should
>have a wide range of global constraints. Good reference
>is SICStus. Both ECLiPSe and SWI seems poor comparing to
>SICStus.

The current interfaces in SICStus and ECLiPSe are for
experts only ; being very close to the engine.  Not a
single property can be guaranteed by those interfaces.
The desire to provide better abstractions has not
yet produced the ultimate language for such extensions.
At some point in the past indexicals looked very promising.

So that is still an open area and your input is welcome!

The achievements of Markus Triska's clpfd implementation in SWI
so far have been to provide the basic constraints in a clean
and robust fashion with highlights as:

* Correctness: Similar to SICStus Prolog open domains are possible
thus extending CLP(FD) towards CLP(Z).  While SICStus reports
overflows above 2^56 as representation errors, SWI has

* No limits (except resource limits, indeed):

?- 7^7^7 #>= X.

Note that other systems implicitly constrain all variables to
a small finite range. Failure in such systems means: No solution
within those limits. If a solution exists outside, you will not
find it.

* Favourable termination properties: All predicates and
constraints in SWI's library(clpfd) terminate.

With this library and SWI's ability to prevent infinite
terms you get a clean language for introductory courses!

Just defer is/2 and its archaic company to a more advanced level.

On Thu, 13 Mar 2008 13:50:47 GMT, ulrich@mips.complang.tuwien.ac.at
(Ulrich Neumerkel) wrote:


>
>The current interfaces in SICStus and ECLiPSe are for
>experts only ; being very close to the engine.  Not a
>single property can be guaranteed by those interfaces.

That what?... What "property"?...

I don't think that SICStus and ECLIPSE interface is "for experts
only'. Actually, both are pretty simple.

>
>With this library and SWI's ability to prevent infinite
>terms you get a clean language for introductory courses!
>

Agree. But actually, very little more.

The whole thread was NOT about criticizing anybody. Thw whole thread
was pretty technical: what is required to have commercial grade
CLP(FD) system in Prolog. Nobody was criticizing SWI and Marcus.

I would suggest to concentrate on technical issyes ratther than "who
did what and who did't what"

A.L.

A.L. <alewando@zanoza.com> writes:
>On Thu, 13 Mar 2008 13:50:47 GMT, ulrich@mips.complang.tuwien.ac.at
>(Ulrich Neumerkel) wrote:
 
>
>That what?... What "property"?...

Monotonicity and similar properties to guarantee that your
extention is a constraint at all.  It is a night mare to
locate such bugs.  I cannot imagine that you never ran into
those.  Just think of unifications that instantanously assign
values to several variables, like (A-B=1-2).

Guaranteed termination would be a bonus.

> Some things are almost inherently associated with community software.
> Not that many developers like documenting and where documenting a single
> piece of the cake is still doable, keeping the dependencies in the
> overall documentation up to date is asking too much. Only big
> communities can fix the documentation problem by regularly publishing
> nice integrated documentation as a book.  Small communities have to work
> with nice, largely automated, tools to get some minimal documentation.

Users can also help writing and improving documentation.
Whoever likes to use the clpfd library should contribute
a little text for the documentation! If you couldn't
understand something and the developer told you how to
do it on comp.lang.prolog or another mailing list,
write a little bit of documentation. It's only fair that you
give something back for what you get.

If users would contribute just a little, they would benefit
a lot more.

Dnia Thu, 13 Mar 2008 11:18:40 -0500
A.L. <alewando@zanoza.com> napisa=C5=82(a):

> I don't think that SICStus and ECLIPSE interface is "for experts
> only'. Actually, both are pretty simple.
>=20
Agree.

> I would suggest to concentrate on technical issyes ratther than "who
> did what and who did't what"
>=20
I support this suggestion! I wanted to talk about technical
issues. Nothing more...

Best regards
--=20
[ Wit Jakuczun    <W.Jakuczun [at] wlogsolutions.com> ]
[ WLOG Solutions  http://www.wlogsolutions.com ]

On Thu, 13 Mar 2008 21:38:35 +0100, bart demoen <bmd@cs.kuleuven.be>
wrote:

>O
>Sorry to be so dense.
>I meant:
>
>	?- X = 1+2, Y is X*3.
>should give an error
>instead of 9.
>
>Source level variables to the right of is/2 (or in < =:= ...)
>should be numbers, and not be evaluated.
>
>Prolog could also have the ability to evaluate source level variables,
>but it should be a separate built-in - and if Prolog would have only one
>predicate, it should be the one that does not evaluate source level vars.
>
>Hope I was more clear this time.

Thanks!

A.L.