Common Lisp - Lazy Evaluation in Tic Tac Toe
fclaude.recoded.cl
Common Lisp - Lazy Evaluation in Tic Tac Toe
1–3 of 3 posts
Re: Common Lisp - Lazy Evaluation in Tic Tac Toe
#2The DO clause of LOOP has an implicit progn[1], no need to do it explicitly.
Don't be clever with FLET/LABELS, 99% of the time you're doing it out of some vague "information hiding" principle. 99% of the time you end up making it a toplevel function, since local functions just make debugging harder.
A lot of (if (= x 1) ..) and (if (= x 0)) .. type forms are usually a sign you need a readable predicate. (when (foo-p ) .. body)
Array this, array that. Wrap the BOARD type already. You can use classes and structs. This is not Scheme.
Excessive use of REDUCE and LAMBDA is a sign of Schemish hacking. Again, Common Lisp is neither C nor Scheme. The code uses MAP & REDUCE half the time, then AREF, LOOP and SETF the other half. FP-purism is the root cause of code schizophrenia like this. Try to write pronounceable code -- well, relatively speaking.
--
Ohboy, looking at hyperspec I don't see this spelled out, but it works that way, at least when do is the last/only clause.
Re: Common Lisp - Lazy Evaluation in Tic Tac Toe
#3The DO clause of LOOP has an implicit progn[1], no need to do it explicitly. Don't be clever with FLET/LABELS, 99% of the time you're doing it out of some vague "information hiding" principle. 99% of the time you end up making it a toplevel function, since local functions just make debugging harder. A lot of (if (= x 1) ..) and (if (= x 0)) .. type forms are usually a sign you need a readable predicate. (when (foo-p…
I disagree with absolutely everything that you wrote.
I use flet/labels/map/reduce all the time.
I find that in certain places avoiding statefulness can be a readability advantage.
Nothing wrong with using an array as it is simple and easy to understand.
I probably would have used the symbols :x and :o or 'x and 'o (with eql), just for readability, however.
:-)