Dropping attributed variables, consideration

[infradig]

I am considering dropping support for attributed variables, such as they are, in Trealla. Trealla used to do freeze/2 natively and could do so again. Ditto eventually for dif/2 & when/2. Maybe revisit it later.

[guregu]

Native freeze/2, dif/2, when/2 sounds cool. Tau Prolog doesn't support them at all, which is one of the big motivations to work on the WASM stuff for Trealla. After working with Tau a lot, I've been longing to use dif/2 :)
Attributed variables would be great to keep, of course, maybe for experimental stuff — but I'd consider these predicates a little more practical.

[UWN]

Dropping atvs means probably that there will never be a clpz nor clpq. Also, as a general remark on "native" built-in implementations, this has in my view often contributed to more instability than in other implementations. Finding an optimal tiny kernel to start with is certainly not obvious. My armchair advice...

[infradig]

Yes you're right. I was talking out of my hat.

…

On Wed, 10 Aug 2022, 23:23 UWN, ***@***.***> wrote: Dropping atvs means probably that there will never be a clpz nor clpq. Also, as a general remark on "native" built-in implementations, this has in my view often contributed to more instability than in other implementations. Finding an optimal tiny kernel to start with is certainly not obvious. My armchair advice... — Reply to this email directly, view it on GitHub <#3 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFNKSERUVUP4QZLYKIZGS3DVYOUNVANCNFSM56CSOY3Q> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[triska]

freeze/2 is one of the simplest constraints and comparatively easy to implement in C, so this may seem tempting.

dif/2 is already considerably harder to implement correctly, at least if you want it to be in some sense "clever". For example, even after several rounds of correction and rewrites, SWI-Prolog still has elementary mistakes in its (Prolog-based) dif/2 implementation. It stands to reason that a C-based implementation would be a lot harder still to get right and maintain.

Writing clpz and clpb in C will most likely end in a system that, even if you manage to implement it correctly, will be immune to large-scale improvements and rewritings due to its extreme code size. The situation will be similar to Gecode, where implementing significant improvements "is not hard, it is just very tedious" (https://www.gecode.org/users-archive/2017-August/004989.html), and hence not done.

Attributed variables, in addition to enabling the implementation of constraint solvers, also provide O(1) destructive access to terms, and that can be useful to implement graph-based algorithms efficiently.

Personally, I recommend to implement an (ideally: SICStus-compatible) interface for attributed variables as early as possible in a Prolog system, so that its implementation is taken into account at all stages during development. Doing this later may lead to unanticipated complications. Once the interface is available, more and more components (freeze/2, dif/2, when/2 etc. which you mentioned) can be written in Prolog itself, and that keeps the code of the system small and maintainable, and also provides motivation to make the interpreter itself fast. The more you write in C, the less important the Prolog-aspect of the system becomes: Doing as much as possible in C may result in a nice and very large C program, though one that will likely not be very good at running Prolog code.

I say "ideally" SICStus-compatible because SICStus provides correct implementations of dif/2, CLP(B), CLP(FD) and CLP(Q) based on its interface, and this shows that the interface is general enough to implement a wide range of constraint solvers correctly and efficiently.