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.
Sounds like a good language for a quantum computer.
—Randy
On Apr 23, 2020, at 2:52 AM, Jack Waugh tzh9741mq402@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@lists.selflanguage.org http://lists.selflanguage.org/mailman/listinfo/self-interest
Have you read about UFO (United Functions and Objects) by John Sargeant, c.1992? It wasn’t prototype-based, but your email otherwise brought it to mind. There’s an overview paper here: https://www.semanticscholar.org/paper/United-Functions-and-Objects%3A-an-Ove... https://www.semanticscholar.org/paper/United-Functions-and-Objects:-an-Overview-United-an-Sargeant/4be0e681e838f435ab67c0bde9fd6b05c3eef52d and several other papers can be found.
There was a spate of concurrent OO logic language papers in the late 80s/early 90s. A skim of OOPSLA proceedings from that era should turn up many. And before that there was ThingLab (in Smalltalk).
self-interest@lists.selflanguage.org
-
Jack Waugh -
Mario Wolczko -
Randy