Skip to content

Why FuncSug

cl4cnam edited this page Dec 5, 2023 · 3 revisions

When we make a client web program, we code logical parallelism but this is not explicitated. Indeed, when we code addEventListener on several HTML elements, we give them a logically simultaneous ability to react to a DOM event (:warning: This is not an ability to react simultaneously).

In FuncSug, this parallelism is made explicit so that it can be handled more easily.

For example, if I code:

myFirstElement.addEventListener('click', myFunction1)
mySecondElement.addEventListener('click', myFunction2)
restOfProgram()

After execution of these two lines, I get two simultaneous ability to react. It would be more explicit if we could write:

parallel:
	restOfProgram()
	while true:
		await click on myFirstElement
		myFunction1()
	while true:
		await click on mySecondElement
		myFunction2()

This is what is done in FuncSug.

This example doesn't look like a big improvement. But, in many cases, this style can bring a big simplification, see this comparison.

In FuncSug, this style is extended with variant of parallel: parallel exitAfter ... finished, parallel(select ...) and parallel(for ... in ...). In addition, you can interrupt, pause, resume or restart a parallel branch.

In addition, in this example (test it), you'll see that FuncSug saves you the hassle of managing all the combinations of component states.