[Self-interest] Concurrent-constraint Logic Programming

Jack Waugh tzh9741mq402 at sneakemail.com
Thu Apr 23 09:51:46 UTC 2020

I brought up in this forum the subject of the good or poor fit between, on
the one hand, Self's syntax and other principles, and on the other hand,
declarative programming. I want to narrow the topic to a specific sort of
declarative programming: concurrent-constraint logic programming.

I start to imagine a Self-influenced concurrent-constraint language. There
could still be objects and slots, and a slot could still contain code or
data. But the code instead of representing fundamentally an imperative
procedure that can perpetrate side effects but in either event returns a
value (a "function" in the Fortran sense but not necessarily in the
mathematical sense), I'm thinking that the code would receive a logical
interpretation. If the method is called, its sentences would be held to be
true (over the arguments, including the receiver), and the order of
evaluation or elaboration or execution of the sentences could not matter.
The method would execute atomically (over those arguments), or not at all.
Execution would never use a stack. Rather, it would use a trampoline and
could defer tasks by putting them in the trampoline's task queue. Each task
would represent an inferred truth over a collection of arguments.

In the brand of concurrent-constraint execution I am thinking about, it
would be desirable to be able to exclude, through rules that could be
applied to the code before it is admitted into the system, the possibility
of the system ever arriving at a logical contradiction concerning the data
or events it processes from the real world. If logical contradiction could
happen at run time, it might have to result in a major subsystem taking a
dive. I am not contemplating here something like Prolog or Icon, where
contradiction is part of the normal way of life of programming and the
conditional tests are courting contradiction and contradiction is the
normal way of representing falsity. I call those "succeed-fail" languages.

( |
    parent* = something.
   combobulate: a = (
            ifTrue: [b: 'It's true!']
           False: [b: 'No, it isn't!']
| )

Now if we read ifTrue:False: with its usual meaning, there is no problem
here. The value of b will be determined if combobulate: is called. But a
tool for static analysis does not know whether "a" implements a perverted
version of ifTrue:False that executes both branches. In this case, we run
into a logical contradiction, because "b" gets two distinct values, which
can't be allowed in a declarative world. As Leonard Susskind said, if a
thing is one thing, it is definitely not the other.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.selflanguage.org/pipermail/self-interest/attachments/20200423/11685334/attachment.html>

More information about the Self-interest mailing list