finite state machines in scheme

yea. anyone got sum kool examplez?

>>40
Secretly your dad will be watching you.

>>26
Made of cons-pairs. SEXPs allow stuff like (a b . c), created with (cons a (cons b c)). Atomic lists don't allow that.

>>27
But dude, the thing is that "A*B+C" is not a Symta datastructure.
"A*B+C" is just (`+` (`*` A B) C), like Lisp's "'s" is just (quote s)

To make an analogy, you could write a Python parser in Python which produces its AST as a Python object and manipulate Python code that way
Nope.
Python's AST would be impractically hard to manipulate.
See http://norvig.com/python-lisp.html


Python does not have macros. Python does have access to the abstract syntax tree of programs, but this is not for the faint of heart. On the plus side, the modules are easy to understand, and with five minutes and five lines of code I was able to get this:

>>> parse("2 + 2")
['eval_input', ['testlist', ['test', ['and_test', ['not_test', ['comparison',
 ['expr', ['xor_expr', ['and_expr', ['shift_expr', ['arith_expr', ['term',
  ['factor', ['power', ['atom', [2, '2']]]]], [14, '+'], ['term', ['factor',
   ['power', ['atom', [2, '2']]]]]]]]]]]]]]], [4, ''], [0, '']]

>>42
Python does have access to the abstract syntax tree of programs, but this is not for the faint of heart.
So delicate~

>>42
The point in >>26 was that you can easily construct a binary tree with S-expressions and cons cells. Contrast this statement with >>16,17

Also >>42
Nope.
Way to entirely miss the point and attack the irrelevant part of the analogy.

http://norvig.com/python-lisp.html
The two main drawbacks of Python from my point of view are (1) there is very little compile-time error analysis and type declaration, even less than Lisp, and (2) execution time is much slower than Lisp, often by a factor of 10 (sometimes by 100 and sometimes by 1). Qualitatively, Python feels about the same speed as interpreted Lisp, but very noticably slower than compiled Lisp. For this reason I wouldn't recommend Python for applications that are (or are likely to become over time) compute intensive (unless you are willing to move the speed bottlenecks into C). But my purpose is oriented towards pedagogy, not production, so this is less of an issue.

Yet mercurial happened...

>>46
Which is precisely why people prefer git over Mercurial.

>>35


ever heard of proper tail calls?

>>> parse("2 + 2")
['eval_input', ['testlist', ['test', ['and_test', ['not_test', ['comparison',
 ['expr', ['xor_expr', ['and_expr', ['shift_expr', ['arith_expr', ['term',
  ['factor', ['power', ['atom', [2, '2']]]]], [14, '+'], ['term', ['factor',
   ['power', ['atom', [2, '2']]]]]]]]]]]]]]], [4, ''], [0, '']]
Is… this as ugly as it looks?

>>49
>>> (parse "(+ 2 2)")
(+ 2 2)
>>>