<hunar>
Hi Regenaxer :) I have a question about something that a macro can do, I want to know if picolisp can do it ... the code is not the problem and isn't practical in most cases, its just the simplest form of my problem of making shorter code, Lets say I have a function that does something then returns the value (de thing () (prinl
<hunar>
"...") 4) and I always assign that value to a variable (setq A (thing)) Is there anyway that I can move the setq into the function? such that my call will only be (thing A)? that is possible with a macro since I can tell it to return the S-Exp that i want and it'll be replaced at compile time.
<Regenaxer>
Hi Hunar!
<Regenaxer>
Not sure what you mean, but isn't it 'set'?
<Regenaxer>
(de thing (Var) (set Var (something)))
<Regenaxer>
Recommended to do (private) Var
<Regenaxer>
before Var is read
<hunar>
You're right :) this worked (de thing Var (set (car Var) 4)) (thing G) (prinl G) -> 4
<Regenaxer>
:)
<Regenaxer>
A macro is something which is evaluated twice
<hunar>
yes, the first is called expansion i think .. by the way, after all these years was there anything that picolisp can't do due to missing-macros?
<Regenaxer>
I never saw a problem
<hunar>
:D
<Regenaxer>
And in PicoLisp there is 'macro' and read-macros
<Regenaxer>
and what is done with macros in CL is done with FEXPRs in pil
<Regenaxer>
(which are much better in my opinion)
<hunar>
Right :) Its super useful
<Regenaxer>
There are in fact also macros more close to what CL means, but only in PilSrc, when compiling to asm
<Regenaxer>
e.g. 'inline'
<Regenaxer>
But in this view it is the whole PilSrc -> llvm-ir compilation
<hunar>
Another small question, on windows WSL sometimes I see high cpu usage and it turns out to be a picolisp process running but I already closed all the terminals, It happened one or two times this month.. I'm not sure how it happens.. did you encounter anything like that before? It might be WSL
<Regenaxer>
It can happen also in Linux, but it is a fault in the program then
<beneroth>
probably WSL, unless you are starting picolisp processes in background on purpose
<beneroth>
exactly
<beneroth>
high cpu is probably because picolisp repl becomes a busy loop if it looses terminal when it still believes one to be there...so it tries reading from terminal, gets instant feedback, tries again...
<Regenaxer>
yes, this happens
<Regenaxer>
strace helps
<Regenaxer>
it shows pil reading from stdin
<hunar>
How can I reproduce it, do you mean a fault due to my code?
<Regenaxer>
A fault is some infinite loop
<Regenaxer>
but I don't know how to reproduce the stdin issue. Some broken pipe I believe
<hunar>
Ah, I typed (loop) and closed the terminal, it happened
<Regenaxer>
yes, exactly
<Regenaxer>
(loop (+ 3 4)) would terminate
<Regenaxer>
but (loop) does not check signals
<Regenaxer>
so you must kill explicitly
<hunar>
Cool thanks :D
<Regenaxer>
Needs kill -9
<Regenaxer>
Normal kill (15) is not checked for
<Regenaxer>
Pil checks for signals only in certain places
<Regenaxer>
eg on Lisp level code
<Regenaxer>
but (loop) is only a tight internal loop