Automata-based programming - Revision history

Xeroctic: /* Procedural */ minor cleanup

2025-03-27T18:33:18Z

Procedural: minor cleanup

← Previous revision		Revision as of 18:33, 27 March 2025
Line 68:		Line 68:
	==== Procedural ====		==== Procedural ====

	The same task can be solved by thinking in terms of [[finite-state machine]]s. The parsing of a line has three stages: skipping the leading whitespace characters, printing the characters of the first word and skipping the trailing characters. ~~Let's~~ ~~call~~ ~~these~~ ~~automaton states~~ <code>BEFORE</code>, <code>INSIDE</code> and <code>AFTER</code>. An automata-based version of the program could look like this:		The same task can be solved by thinking in terms of [[finite-state machine]]s. The parsing of a line has three stages: skipping the leading whitespace characters, printing the characters of the first word and skipping the trailing characters. These states are called <code>BEFORE</code>, <code>INSIDE</code> and <code>AFTER</code>. An automata-based version of the program could look like this:

	<syntaxhighlight lang="c">		<syntaxhighlight lang="c">
Line 170:		Line 170:

	The program now clearly demonstrates the basic properties of automata-based code:		The program now clearly demonstrates the basic properties of automata-based code:
	* ~~time~~ periods of automaton step executions may not overlap;		* Time periods of automaton step executions may not overlap;
	* ~~the~~ only information passed from the previous step to the next is the explicitly specified ''automaton state''.		* The only information passed from the previous step to the next is the explicitly specified ''automaton state''.

	A finite automaton can be defined by a [[state-transition table]] whose rows stand for the current states, columns stand for the inputs, and cells stand for the next states and actions to perform.		A finite automaton can be defined by a [[state-transition table]] whose rows stand for the current states, columns stand for the inputs, and cells stand for the next states and actions to perform.

Klbrain: Removing merge template; no case made; no support

2025-03-01T12:28:27Z

Removing merge template; no case made; no support

← Previous revision		Revision as of 12:28, 1 March 2025
Line 1:		Line 1:
	{{Short description\|Programming paradigm based on formal automatons}}		{{Short description\|Programming paradigm based on formal automatons}}
	{{Other uses\|Automata-based programming (Shalyto's approach)}}		{{Other uses\|Automata-based programming (Shalyto's approach)}}

	{{Merge from\|Automata-based programming (Shalyto's approach)\|date=February 2025}}
	'''Automata-based programming''' is a [[programming paradigm]] in which the program or part of it is thought of as a model of a [[finite-state machine]] (FSM) or any other (often more complicated) formal automaton (see [[automata theory]]). Sometimes a potentially infinite set of possible states is introduced, and such a set can have a complicated structure, not just an enumeration.		'''Automata-based programming''' is a [[programming paradigm]] in which the program or part of it is thought of as a model of a [[finite-state machine]] (FSM) or any other (often more complicated) formal automaton (see [[automata theory]]). Sometimes a potentially infinite set of possible states is introduced, and such a set can have a complicated structure, not just an enumeration.

TheDragonFire: Added {{Merge from}} tag

2025-02-17T17:03:59Z

Added {{Merge from}} tag

← Previous revision		Revision as of 17:03, 17 February 2025
Line 2:		Line 2:
	{{Other uses\|Automata-based programming (Shalyto's approach)}}		{{Other uses\|Automata-based programming (Shalyto's approach)}}

			{{Merge from\|Automata-based programming (Shalyto's approach)\|date=February 2025}}
	'''Automata-based programming''' is a [[programming paradigm]] in which the program or part of it is thought of as a model of a [[finite-state machine]] (FSM) or any other (often more complicated) formal automaton (see [[automata theory]]). Sometimes a potentially infinite set of possible states is introduced, and such a set can have a complicated structure, not just an enumeration.		'''Automata-based programming''' is a [[programming paradigm]] in which the program or part of it is thought of as a model of a [[finite-state machine]] (FSM) or any other (often more complicated) formal automaton (see [[automata theory]]). Sometimes a potentially infinite set of possible states is introduced, and such a set can have a complicated structure, not just an enumeration.

Mathnerd314159: change paradigms template to navbox (see Template talk:Programming paradigms#too long)

2024-02-01T22:38:37Z

change paradigms template to navbox (see Template talk:Programming paradigms#too long)

← Previous revision		Revision as of 22:38, 1 February 2024
Line 1:		Line 1:
	{{Short description\|Programming paradigm based on formal automatons}}		{{Short description\|Programming paradigm based on formal automatons}}
	{{Other uses\|Automata-based programming (Shalyto's approach)}}		{{Other uses\|Automata-based programming (Shalyto's approach)}}
⚫	{{Programming paradigms}}

	'''Automata-based programming''' is a [[programming paradigm]] in which the program or part of it is thought of as a model of a [[finite-state machine]] (FSM) or any other (often more complicated) formal automaton (see [[automata theory]]). Sometimes a potentially infinite set of possible states is introduced, and such a set can have a complicated structure, not just an enumeration.		'''Automata-based programming''' is a [[programming paradigm]] in which the program or part of it is thought of as a model of a [[finite-state machine]] (FSM) or any other (often more complicated) formal automaton (see [[automata theory]]). Sometimes a potentially infinite set of possible states is introduced, and such a set can have a complicated structure, not just an enumeration.
Line 692:		Line 691:
	* <cite id="CITEREFPolikarpova2009">Polikarpova N. I., Shalyto A. A. [http://is.ifmo.ru/books/_book.pdf Automata-based programming] SPb.: Piter. 2009 (rus)</cite>		* <cite id="CITEREFPolikarpova2009">Polikarpova N. I., Shalyto A. A. [http://is.ifmo.ru/books/_book.pdf Automata-based programming] SPb.: Piter. 2009 (rus)</cite>
	* [http://is.ifmo.ru ITMO University, "Programming Technology" department]		* [http://is.ifmo.ru ITMO University, "Programming Technology" department]

		⚫	{{Programming paradigms navbox}}

	[[Category:Programming paradigms]]		[[Category:Programming paradigms]]

HeyElliott: MOS:NOTE

2023-10-17T01:23:45Z

MOS:NOTE

← Previous revision		Revision as of 01:23, 17 October 2023
Line 70:		Line 70:
	==== Procedural ====		==== Procedural ====

	The same task can be solved by thinking in terms of [[finite-state machine]]s. ~~Note that the~~ parsing of a line has three stages: skipping the leading whitespace characters, printing the characters of the first word and skipping the trailing characters. Let's call these automaton states <code>BEFORE</code>, <code>INSIDE</code> and <code>AFTER</code>. An automata-based version of the program could look like this:		The same task can be solved by thinking in terms of [[finite-state machine]]s. The parsing of a line has three stages: skipping the leading whitespace characters, printing the characters of the first word and skipping the trailing characters. Let's call these automaton states <code>BEFORE</code>, <code>INSIDE</code> and <code>AFTER</code>. An automata-based version of the program could look like this:

	<syntaxhighlight lang="c">		<syntaxhighlight lang="c">
Line 320:		Line 320:
	</syntaxhighlight>		</syntaxhighlight>

	~~''Note.'' —~~ To minimize changes not directly related to the subject of the article, the [[input/output]] <code>getchar</code> and <code>putchar</code> functions from the standard library of [[C (programming language)\|C]] are being used.		To minimize changes not directly related to the subject of the article, the [[input/output]] <code>getchar</code> and <code>putchar</code> functions from the standard library of [[C (programming language)\|C]] are being used.

	The [[State pattern\|state design pattern]] is a way for an object to change its behavior at runtime according to its internal state ''without resorting to large conditional statements or table lookups'' thanks to virtual function calls. Its main advantage over code using large conditional statements is that state-specific code is distributed across different objects rather than localized in a monolithic block, which improves maintainability. Its main advantages over code using state-transition tables are that virtual function calls are often more efficient than table lookups, that state-transition criteria are more explicit than in tabular format, and that it is easier to add actions accompanying state transitions. However it introduces a new problem: the number of classes makes the code less compact than the other approaches. The program using the state design pattern could look like this:		The [[State pattern\|state design pattern]] is a way for an object to change its behavior at runtime according to its internal state ''without resorting to large conditional statements or table lookups'' thanks to virtual function calls. Its main advantage over code using large conditional statements is that state-specific code is distributed across different objects rather than localized in a monolithic block, which improves maintainability. Its main advantages over code using state-transition tables are that virtual function calls are often more efficient than table lookups, that state-transition criteria are more explicit than in tabular format, and that it is easier to add actions accompanying state transitions. However it introduces a new problem: the number of classes makes the code less compact than the other approaches. The program using the state design pattern could look like this:

OAbot: Open access bot: doi updated in citation with #oabot.

2023-08-23T20:59:14Z

Open access bot: doi updated in citation with #oabot.

← Previous revision		Revision as of 20:59, 23 August 2023
Line 606:		Line 606:
	\| doi = 10.1145/364175.364185		\| doi = 10.1145/364175.364185
	\| s2cid = 17253809		\| s2cid = 17253809
			\| doi-access = free
	}}		}}
	</ref>		</ref>

HeyElliott: /* Object-oriented programming relationship */ WP:N'T

2023-07-21T22:59:59Z

Object-oriented programming relationship: WP:N'T

← Previous revision		Revision as of 22:59, 21 July 2023
Line 649:		Line 649:
	Thus, on the one hand, objects from object-oriented programming can be considered as automata (or models of automata) whose ''state'' is the combination of private fields, and one or more methods are considered to be the ''step''. Such methods must not call each other nor themselves, neither directly nor indirectly, otherwise the object can not be considered to be implemented in an automata-based manner.		Thus, on the one hand, objects from object-oriented programming can be considered as automata (or models of automata) whose ''state'' is the combination of private fields, and one or more methods are considered to be the ''step''. Such methods must not call each other nor themselves, neither directly nor indirectly, otherwise the object can not be considered to be implemented in an automata-based manner.

	On the other hand, object is good for implementing a model of an automaton. When the automata-based approach is used within an object-oriented language, an automaton model is usually implemented by a class, the state is represented with private fields of the class, and the step is implemented as a method; such a method is usually the only non-constant public method of the class (besides constructors and destructors). Other public methods could query the state but ~~don't~~ change it. All the secondary methods (such as particular state handlers) are usually hidden within the private part of the class.		On the other hand, object is good for implementing a model of an automaton. When the automata-based approach is used within an object-oriented language, an automaton model is usually implemented by a class, the state is represented with private fields of the class, and the step is implemented as a method; such a method is usually the only non-constant public method of the class (besides constructors and destructors). Other public methods could query the state but do not change it. All the secondary methods (such as particular state handlers) are usually hidden within the private part of the class.

	== See also ==		== See also ==

Cedar101: /* Traditional program */ lang="output"

2022-03-18T06:13:54Z

Traditional program: lang="output"

← Previous revision		Revision as of 06:13, 18 March 2022
Line 61:		Line 61:
	yields:		yields:

	<syntaxhighlight lang="~~text~~">		<syntaxhighlight lang="output">
	foo		foo
	qux		qux

199.167.89.47 at 18:10, 21 October 2021

2021-10-21T18:10:28Z

← Previous revision		Revision as of 18:10, 21 October 2021
Line 1:		Line 1:
	{{Short description\|Programming paradigm based on ~~automata~~}}		{{Short description\|Programming paradigm based on formal automatons}}
	{{Other uses\|Automata-based programming (Shalyto's approach)}}		{{Other uses\|Automata-based programming (Shalyto's approach)}}
	{{Programming paradigms}}		{{Programming paradigms}}

199.167.89.59 at 18:06, 21 October 2021

2021-10-21T18:06:51Z

← Previous revision		Revision as of 18:06, 21 October 2021
Line 1:		Line 1:
			{{Short description\|Programming paradigm based on automata}}
	{{Other uses\|Automata-based programming (Shalyto's approach)}}		{{Other uses\|Automata-based programming (Shalyto's approach)}}
	{{Programming paradigms}}		{{Programming paradigms}}