[Self-interest] Concurrent-constraint Logic Programming

Randy randy.smith at gmail.com
Thu Apr 23 14:32:47 UTC 2020


Sounds like a good language for a quantum computer. 

—Randy


> On Apr 23, 2020, at 2:52 AM, Jack Waugh <tzh9741mq402 at sneakemail.com> wrote:
> 
> 
> 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.
>    b.
>    combobulate: a = (
>         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.
> _______________________________________________
> Self-interest mailing list
> Self-interest at lists.selflanguage.org
> http://lists.selflanguage.org/mailman/listinfo/self-interest
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.selflanguage.org/pipermail/self-interest/attachments/20200423/6c34498d/attachment.html>


More information about the Self-interest mailing list