This reproduces the behavior of yours (possibly too) exactly, including giving the user 9 guesses and saying "1 tries" if you get it right the first time. The return value is different though.
(def guess ((o tries 1) (o r (rand 100)))
(when (< tries 10)
(pr "your guess: ")
(let y (read)
(prn)
(if (is y r)
(do (prn "yay")
(pr "you got it in " tries " tries."))
(do (prn y " is too " (if (< y r) "low" "high"))
(guess (+ tries 1) r))))))
It's a good start -- it works, which always is a plus :)
However, a few comments about your version:
- You use an iterative 'while, rather than the tail-recursive approach that Paul Graham posted. Both end up eventually as tail-recursive code, however, I think that it's better, in this case, to write the tail-recursion directly. The reason for this is that in your version, you have to explicitly "break out" of the loop (by setting 'tries to 1), while in Paul's version, he just doesn't call the next "iteration".
- You should probably use 'prn for the last message -- when I run this, "nil" gets tacked on to the end of the message.
- This is more just a matter of convention, than an actual problem, but your indentation isn't completely standard. Usually, body code for macros is only indented by two spaces. Also, having several tokens on one line can get a bit confusing, and in a form like 'with, I think it helps to organize them. I think the start of your code could be more readable like this:
If all the following lines go together as a group, and the arguments on the first line aren't part of that group, then I'll indent the following lines differently to emphasize the grouping:
(each (k v) mytable
(prn "my key is " k)
(prn "and my value is " v))
It doesn't matter to me whether it's a macro or a function:
(copy (obj a 1)
'b 2
'c 3)
I use the two space indentation a lot more with macros than I do with functions because many macros use the pattern of some arguments followed by a body and not many functions do, but I don't change my indentation depending on whether it's a function or a macro.
If the lines after the first line don't fall into their own group, then I'll line up the arguments:
(+ '(a b c d)
'(e f g h)
'(i jk))
(map (fn (x) ...)
(generate-my-list ...))
For me the important consideration is using indentation to show which arguments go together.
I think there's a general tradition in Lisp indentation, which works essentially as follows:
Function calls are indented with all the arguments starting at the same column, for example:
(calculate-fn-of arg1
arg2
arg3)
Macro calls are indented with the arguments two spaces in, for example:
(while (< x 10)
(prn x)
(++ x))
This is usually done to emphasize the "body" of the macro arguments. So in macros which take several arguments before the "body" code, you'd put those arguments either on the same line, or indented in some way to distinguish them from the body. For example:
(with (var1 val1
thing2 val2
var3 expr3)
(do
(stuff)
(with-vars)))
However, some forms are indented differently for clarity. This doesn't seem to be as standardized. An example would be Arc's 'if macro. It makes sense to indent it with all the conditions on one line, but where do the result forms go? Possibilities are:
I just noticed that there is a file named CONVENTIONS in Anarki that states comment and indentation conventions for arc. They say pretty much what has been said so far, but may be worth looking at if you are interested.
I think that your first example is probably best in terms of compactness and clarity (associating each condition with its corresponding code). The completely straight indentation can be difficult to scan quickly if you have more than one condition. IMO, the only problem with your first example is when the conditions span more than one line or are very long.
In terms of 'if, I was looking through some of pg's code just now, and noticed that he does use the wavy form of indentation. Thus, if you're big on proof by authority, the correct form of indentation for 'if would be the wavy one...
However, in this case I agree with Adlai: pg had even planned on getting ppr to "properly indent long ifs". I presume that means to implement the wavy feature. It's also the convention for Anarki, according to the CONVENTIONS file.
So, here's what I'm thinking should be done for ifs:
1) If you only have three expressions, if-then-else, use:
(if a
b
c)
1) If you like the format, and the expressions are very short use:
(if a b
c d
...
e)
3) If you don't like that form, or the expressions are longer, use:
(if (a )
(b )
(c )
(d )
(e ))
I'm not sure whether to use one or two spaces between clauses. The anarki conventions file uses two spaces. Elsewhere I've seen only one space. So, which is it? Now or never ;)
(I'm writing a new version of ppr with proper indentation of forms, in case you wanted to know why I'm so interested in the indentation question)
I think two is better, because it a) clearly distinguishes it as indentation (rather than just an accidental #\space), and b) it's consistent with the indentation of macros & co.
Should it depend on whether they fit on one line or not? If they don't fit, should it still be like b., just with the second part spilling onto the next line?
Your first version is the one currently implemented by ppr.arc. If you would like, you can write the indentation function for your second version (it can even include the "; else")
Otherwise I think that the first version is generally clearer, and the second is rarely needed, as the value of the case statement can't usually be very long. Could you give me an example where you use your second version?
Sure; here's something from my tagged-unions.arc on Anarki (Arc 2). It's responsible for parsing the types specified for slots in the tagged union:
(each type-frag types
; Assemble the ('type name) pairs into two lists, so that we can iterate
; through them.
(case (type type-frag)
; If it's a symbol, then we're defining a new name; add a new set of
; values, and go.
sym
(do
(zap [cons type-frag _] names)
(zap [cons nil _] values))
; Otherwise, we're adding a value to an existing variant.
cons
; I changed my mind about the order (now it's (name pred?) instead of
; (pred? name)), so I'm reversing it here.
(zap [cons (rev type-frag) _] (car values))
; else
(err "Invalid member of tagged union declaration.")))
I should also add (just as another data point) that my multi-condition ifs look like that too, and single-condition ifs look like the following:
(def macexn (n expr)
" Macroexpand `expr' `n' times. NB: `expr' *is* evaluated!
See also [[macex1]] [[macex]] "
(if (and (number n) (> n 0))
(macexn (- n 1) (macex1 expr))
expr))
I'm not hugely wedded to any of my conventions, though, and I haven't coded in Arc for quite a while anyway; this isn't intended to get you to change anything or convert people to my style. As I said, it's just another data point.
The nil is the return value of the function. Since the last thing you did was an assignment, is 'nil. It only shows up like that on the repl, which prints both stdout and return values. It is true that printing a newline first would make it show up in the next line, but it doesn't really matter if you're making it into a web service since the nil won't be printed.
