Looking for help in learning LISP programming

[eti]

Hello everyone

Having started to master the incredible "emacs" editor (sorry, *OS*) couple of years ago, I was, naturally, attracted to what makes it run - IE "LISP" language. Being that I am definitely NOT a master mathematician, but being a very logic-minded person, I am hoping people could point me in a suitable direction so as to pick up on some of the abstract concepts used, such as "lambda", etc... it's quite a mind-bender, but by no means insurmountable.

Also, what on earth is a "state machine", please? I think I have a delicate grasp on it, but it's slipping away as a barely formed thought.

Thank you, most grateful indeed. 

[rstofer]

Also, what on earth is a "state machine", please? I think I have a delicate grasp on it, but it's slipping away as a barely formed thought.

I know less than nothing about Lisp but there are plenty of books.  Amazon has them and so does Alibris.

As to state machines, they are nothing more than a 'switch' statement with a lot of 'case' statements.  Think of it as the kid's game 'Simon Says'.  You can't make a move until 'Simon Says'.

First, we have a variable 'state' which indexes into the case statements.  In each case, there is the opportunity, under some condition, or no condition at all, to change the 'state' variable so that the next time the 'switch' statement is executed, it changes to a different state, a different case.

Sometimes the 'case' values are set with an 'enum' so that the case labels make some kind of sense.

This page has a couple of FSMs.  Note the 'enum' in the first example and then look where the author didn't carry the idea forward.  It just makes sense to name the states.

The second example is far more complex and tries to mimic the diagram of the FSM.  I would still want to name the states.

https://stackoverflow.com/questions/31100824/finite-state-machine-in-c

We're in a state and when Simon says, we change to another state for the next pass through the switch statement.  Otherwise, we keep executing the code for the present state every time the switch statement is executed.  Simon Says!

[tggzzz]

As to state machines, they are nothing more than a 'switch' statement with a lot of 'case' statements.  Think of it as the kid's game 'Simon Says'. 

That is one implementation technique, which is valid for simple small FSM with few states and events.

As FSMs grow larger over time (which they always do), those very quickly become unmaintainable rats nests. Then other implementation techniques become more appropriate.

Two other techniques are:

• a 2D array of function pointers to the functions implementing the actions. One dimension is the state, the other is the event. Benefit: it forces you to explicitly consider and define what happens in all circumstances, including "don't care should not happen" event/state combinations
• an OOP design, where each state is a class, each event is a method, and each action is method body. Benefit: easy to understand hierarchical FSM implementation, where each class only contains the methods relevant to that state. The "don't care should not happen" event/state combinations are implemented and trapped in an abstract superclass

There are, of course, other implementation techniques, including hardware. I would expect LISP techniques to include (but not be limited to) anonymous lambda functions which implement actions.