Hey Dean, I think that, in general, you want to quote a sym argument to a function when you want to change the value of that symbol. For example:
: (setq A 1) # Set the value of A to 1 -> 1 : (inc A) # Evaluate A, *then* pass the result to inc -> 2 : A -> 1 : (inc 'A) # Pass the symbol A to inc -> 2 : A -> 2 In (inc A), first A got evaluated to 1, and that 1 was passed to inc, so it was the same as (inc 1). In (inc 'A), the *symbol* A got passed to inc, and inc recognised this and changed what A evaluates to. Another function where this is clear is in pop. It returns the CAR of a list and, if given a symbol, it will return the CAR *and* change the value of the symbol. Here's an example: : (setq A (1 2 3 4)) -> (1 2 3 4) : A -> (1 2 3 4) : (pop A) # evaluate A, pass that to pop -> 1 : A -> (1 2 3 4) : (pop 'A) # pass the symbol A to pop -> 1 : A -> (2 3 4) Like with inc in the last example, in (pop A) A is evaluated first, to (1 2 3 4), so what the interpreter sees is (pop (1 2 3 4)). In contrast, in (pop 'A) the *symbol* A is passed to pop, so the interpreter both returns the CAR of A, *and *changed the value of the symbol A. I think that, in general, you want to quote a symbol when you want to change the value of that symbol when the function is evaluated. I think that not every function can do this, and I think it is called "destruction." set is another function that works differently if the argument is quoted or not: : (setq S NIL) -> NIL : S -> NIL : (set S 1) !? (set S 1) NIL -- Protected symbol ? (set 'S 1) -> 1 ? S -> 1 ? : (set 'S (1 2 3 4)) -> (1 2 3 4) : S -> (1 2 3 4) : (set S 'a) -> a : S -> (a 2 3 4) When the symbol argument to set is quoted, the value of the symbol is changed. When it isn't, set expect the argument to be a cons pair (a list), and changes the value of the CAR of that cons pair, changing the value of S in the process. So, if you wanna change what S is using set, quote it. If S is a list and you wanna change its innards, don't quote it. This last is actually the part that I understand the least, so if you feel confused don't worry: that's probably because I don't know very well what 'm talking about. That is more or less all I know. Here are some functions that behave different if you quote or not their symbol argument: inc, dec, push, pop, set, setq I recommend you go out and play with them, and if you have any questions, you'd do us a huge favor by asking them. P.S. I'm still new to picolisp, so don't take any of what I say as gospel. And if anyone can confirm or expand on what I've said, I'd appreciate it a lot. On Thu, Dec 8, 2016 at 3:08 PM, Alexander Burger <[email protected]> wrote: > Hi Dean, > > > I'm used to sprinkling print statements in my code as a way of tracking > > down bugs but they seem to be affecting my code more than I was > expecting. > > I recommend to look at 'trace' and 'msg'. They both output to stderr and > don't > interfer with the expressions. > > 'trace' shows what argumments are passed, and what the functions return. > See the > tutorial for examples. > > 'msg' prints its argument to stderr *and* returns it, so it does not > destroy the > flow. For example: > > (if (condition) > (doTrue) > (doFalse1) > (doFalse2) ) > > Now this would be wrong: > > (if (condition) > (prinl "true") > (doTrue) > (doFalse1) > (doFalse2) ) > > But this is all right: > > (if (msg (condition) " condition") > (msg (doTrue) " true") > (msm (doFalse1) " false") > (doFalse2) ) > > Even easier is not to modify the source at all, and do instead, before > starting > the program > > (mapc trace '(condition doTrue doFalse1)) > > And/or use 'debug' to single-trace your program. Again see the tutorial. > > > > I've also realised I'm never quite sure when and when I shouldn't > precede a > > symbol with a quote e.g. as a function argument in a (debug 'Symbol) > > statement and wonder if there are some very simple rules of thumb. > > It is noted in the reference. If an argument is noted as eg. 'any it means > that > the argument is *evaluated* (not necessarily that you actually need to > write a > quote). > > Cheers, > - Alex > -- > UNSUBSCRIBE: mailto:[email protected]?subject=Unsubscribe >
