3 ms·

This seems very interesting - its like a graph based computation language! OP - it seems to me that executions of programs in this context are kind of orientati

This seems very interesting - its like a graph based computation language! OP - it seems to me that executions of programs in this context are kind of orientations through the graph by drawing arrows all in one direction or the other.. So can this run programs in both directions? For example, orienting the NAND gate from "X NAND Y" to X and Y (i.e providing X NAND Y as say, TRUE) would generate the X and Y that could lead to the input? If we added that functionality to the basic gates (i.e allow running OR in reverse and have it return {(X=1,Y=0), (X=0,Y=1)} when given input (X OR Y=1)), and accumulated the possibilities at each step as a tree. Of course, it could take very long to run. Actually, maybe it would even be possible simply fill in certain nodes and propagate out to all connected nodes, keeping track of possible inputs. So it can complete the whole graph (or connected component to be precise) with possible values given any random nodes filled out. So it can give you all possible executions subject to restrictions on any nodes values. That would be awesome! OP - Does that make any sense? If it does, I may try to implement it and see what kinds of cool things we can do with it.

kilburn 12y ago
To me this seems to be exactly what constraint programming is about. Think prolog: you define the relationships (edges in this computation graph), instantiate some values and then ask the solver to fill the rest. Is there anything fundamentally different in your idea?
- petar 12y ago
  Yes. All the functional programming language had the right idea (as you point out). But not the right grammar. Escher has 3 grammar rules (reflex, circuit and valve). All these other languages have much much more. That's the point.
- petar 12y ago
  The language for expressing constraints is what different, not the meaning. People are confused because they properly evaluate that you can do with this language what you can do with any other. But only up to a point of scale. Then the bugs that other languages make you introduce catch up with you. And you can't produce more software because you have to spend too much time fixing bugs of old software. In Escher, every circuit without valves is forever closed as design: for the same reason electrical circuits are rarely recalled. Did you ever wonder why that is?
petar 12y ago
The whole point is that the gate-designer decides if their gate works in various directions (there are usually much more than 2 or 3). And this simply means that if they get a stream of events coming in in the wrong order, they can choose how to "complain": They can stay silent and ignore the broken language sent to them. Or they can throw a panic and halt the entire program. You decide. The NAND gate makes little sense to go in anything but one direction. But a PLUS gate or the REASON gate make sense in multiple directions. You can read more about this here: http://www.maymounkov.org/memex/abstract http://www.maymounkov.org/memex/abstract
- zaptheimpaler 12y ago
  Does the current implementation have support for reversible gates?
  - petar 12y ago
    Yes. Be patient a few more weeks, as I have other obligations too. I will have demos how you can make your own gesture-controlled robotics at home, using Escher bindings for the gobot.io library

kilburn 12y ago

To me this seems to be exactly what constraint programming is about. Think prolog: you define the relationships (edges in this computation graph), instantiate some values and then ask the solver to fill the rest. Is there anything fundamentally different in your idea?

petar 12y ago
Yes. All the functional programming language had the right idea (as you point out). But not the right grammar. Escher has 3 grammar rules (reflex, circuit and valve). All these other languages have much much more. That's the point.
petar 12y ago
The language for expressing constraints is what different, not the meaning. People are confused because they properly evaluate that you can do with this language what you can do with any other. But only up to a point of scale. Then the bugs that other languages make you introduce catch up with you. And you can't produce more software because you have to spend too much time fixing bugs of old software. In Escher, every circuit without valves is forever closed as design: for the same reason electrical circuits are rarely recalled. Did you ever wonder why that is?

petar 12y ago

The whole point is that the gate-designer decides if their gate works in various directions (there are usually much more than 2 or 3). And this simply means that if they get a stream of events coming in in the wrong order, they can choose how to "complain": They can stay silent and ignore the broken language sent to them. Or they can throw a panic and halt the entire program. You decide. The NAND gate makes little sense to go in anything but one direction. But a PLUS gate or the REASON gate make sense in multiple directions. You can read more about this here: http://www.maymounkov.org/memex/abstract http://www.maymounkov.org/memex/abstract

zaptheimpaler 12y ago
Does the current implementation have support for reversible gates?
- petar 12y ago
  Yes. Be patient a few more weeks, as I have other obligations too. I will have demos how you can make your own gesture-controlled robotics at home, using Escher bindings for the gobot.io library