4 ms·

So what would such a language look like?

eternalban 5y ago
A 'table' scheme for syntactic forms which would be compiled to an FSM (equiv to a regular) language for processing. Assuming each row has a tuple value, any document definition language (such as JSON) would do as the front-end that spits out the RL. https://en.wikipedia.org/wiki/Regular_language https://en.wikipedia.org/wiki/Regular_language
- airbreather 5y ago
  I am a functional safety engineer for industrial plant and equipment and this exactly what I do for designing the sequencing and safety systems for large fired equipment. Either single FSM or a hierarchy of them when there is multiple burners. I wrote myself a package using PyQt that sort of looks like a special spreadsheet that allows the combustion engineers to specify and also simulate the logic on a scan by scan basis. The supporting logic "engine" is actually so simple as to be effectively 4 bitwise ops on bit packed words, per state (I use Mealy machines so the outputs are coupled directly and synchronously to states). Bonus is first up alarms and whats holding you out from next state all come for free in the logic used and you can derive a bunch of test cases automatically. The sim/spec tool could export code ready to import to the controller, but we haven't had the economies of scale to support the required generalised tool testing this would require, but it does generate a bunch of hex codes that are the "configuration" that controls the functionality, interpreted by the 'engine' A bunch of other bonuses, it allows you collect notes in a rich text doc behind every transition or condition cell and it can export these to make an easier to read human readable spec, it has an OPC server so you can couple it up to a HMI and do some basioc training or simulation demonstration, or you can bolt it onto an existing machine and see how well it "shadows" it if you are doign a retrofit or brownfields job. The improved quality of outcomes and traceability etc (all the good engineering things desireable) yielded by an executable specification has increased by at least an order of magnitude by having a tool of this nature. Previously most systems like this were effectively done by specifying with a "crappy narrative". This usually entailed, at best, a collection of vague thoughts about some things that were wanted, and some things that weren't, often some in conflict, and a not mentioning a bunch of negelected things. You then rolled the dice on the programmer and hoped they knew enough to ask the 3000 needed questions to somehow come up with adequately coded functionality. New tool is way, way better. A final note, a joke I am sure most of you know, about why English is a poor specifying language and the sort of thing that drove me to take this path (with English it's all about assumed context) A wife asks her husband, a software engineer, "Could you please go shopping for me and buy one carton of milk, and if they have eggs, get 6!" A short time later the husband comes back with 6 cartons of milk. The wife asks him, "Why the hell did you buy 6 cartons of milk?" He replied, "They had eggs."
choeger 5y ago
More interestingly: What would it mean? What is actually specified? For instance, when I specify a messaging protocol I could use a FSM but would this implicitly assume that there is some form of "connection" between client and server that consists of a state in each of them. So whenever I specify something, I need to start with a declaration of the entities and the list of possible events (and these events would carry data). This way, the spec has an unintended effect on the implementation. Let's assume that I have some universal way to represent this data in all target languages (complicated but doable). If I then want to compile this FSM spec into test cases, I must offer some interface that mirrors the entities and events, essentially forcing me to explicitly program a FSM. This is suboptimal because my implementation might not actually need this level of abstraction. A simple embedded C program might be described as a FSM but it could be implemented as a sequence of instructions. Of course, we could also switch to integration testing, passing messages over sockets, etc. but then we would have to program the scaffolding around our mock client/server component and to benefit from the automatic test case generation we would have to either parse and interpret these automatic test cases or program our mock in a form that is defined by the specification output. What I am trying to say is that there probably won't be a universal spec language. Instead, it should fit into the implementation eco system.

A 'table' scheme for syntactic forms which would be compiled to an FSM (equiv to a regular) language for processing. Assuming each row has a tuple value, any document definition language (such as JSON) would do as the front-end that spits out the RL. https://en.wikipedia.org/wiki/Regular_language https://en.wikipedia.org/wiki/Regular_language

airbreather 5y ago
I am a functional safety engineer for industrial plant and equipment and this exactly what I do for designing the sequencing and safety systems for large fired equipment. Either single FSM or a hierarchy of them when there is multiple burners. I wrote myself a package using PyQt that sort of looks like a special spreadsheet that allows the combustion engineers to specify and also simulate the logic on a scan by scan basis. The supporting logic "engine" is actually so simple as to be effectively 4 bitwise ops on bit packed words, per state (I use Mealy machines so the outputs are coupled directly and synchronously to states). Bonus is first up alarms and whats holding you out from next state all come for free in the logic used and you can derive a bunch of test cases automatically. The sim/spec tool could export code ready to import to the controller, but we haven't had the economies of scale to support the required generalised tool testing this would require, but it does generate a bunch of hex codes that are the "configuration" that controls the functionality, interpreted by the 'engine' A bunch of other bonuses, it allows you collect notes in a rich text doc behind every transition or condition cell and it can export these to make an easier to read human readable spec, it has an OPC server so you can couple it up to a HMI and do some basioc training or simulation demonstration, or you can bolt it onto an existing machine and see how well it "shadows" it if you are doign a retrofit or brownfields job. The improved quality of outcomes and traceability etc (all the good engineering things desireable) yielded by an executable specification has increased by at least an order of magnitude by having a tool of this nature. Previously most systems like this were effectively done by specifying with a "crappy narrative". This usually entailed, at best, a collection of vague thoughts about some things that were wanted, and some things that weren't, often some in conflict, and a not mentioning a bunch of negelected things. You then rolled the dice on the programmer and hoped they knew enough to ask the 3000 needed questions to somehow come up with adequately coded functionality. New tool is way, way better. A final note, a joke I am sure most of you know, about why English is a poor specifying language and the sort of thing that drove me to take this path (with English it's all about assumed context) A wife asks her husband, a software engineer, "Could you please go shopping for me and buy one carton of milk, and if they have eggs, get 6!" A short time later the husband comes back with 6 cartons of milk. The wife asks him, "Why the hell did you buy 6 cartons of milk?" He replied, "They had eggs."

choeger 5y ago

More interestingly: What would it mean? What is actually specified? For instance, when I specify a messaging protocol I could use a FSM but would this implicitly assume that there is some form of "connection" between client and server that consists of a state in each of them. So whenever I specify something, I need to start with a declaration of the entities and the list of possible events (and these events would carry data). This way, the spec has an unintended effect on the implementation. Let's assume that I have some universal way to represent this data in all target languages (complicated but doable). If I then want to compile this FSM spec into test cases, I must offer some interface that mirrors the entities and events, essentially forcing me to explicitly program a FSM. This is suboptimal because my implementation might not actually need this level of abstraction. A simple embedded C program might be described as a FSM but it could be implemented as a sequence of instructions. Of course, we could also switch to integration testing, passing messages over sockets, etc. but then we would have to program the scaffolding around our mock client/server component and to benefit from the automatic test case generation we would have to either parse and interpret these automatic test cases or program our mock in a form that is defined by the specification output. What I am trying to say is that there probably won't be a universal spec language. Instead, it should fit into the implementation eco system.