ygrek has quit [Remote host closed the connection]
neuroevolutus has joined #picolisp
neuroevolutus has quit [Ping timeout: 256 seconds]
rob_w has joined #picolisp
<beneroth>
Good morning abu[7]
<abu[7]>
Moin beneroth!
<beneroth>
A question about (state ...) - does the order of the cases matter? I'd assume they are checked in order, so more-likely cases at the top might give a (very minimal) boost?
<abu[7]>
Right
<abu[7]>
e
<abu[7]>
oops
<beneroth>
steno? :)
<abu[7]>
No, wrong window
<abu[7]>
Of course the order also matters logically
<beneroth>
I just had the idea that (state ...) could be self-optimizing, similar to how access of symbol properties is moving often accessed properties to the top. But I guess the re-arranging costs more than the probably gain, unless the state list is very huge
<abu[7]>
T
<beneroth>
how does the order matter logically in (state ...) ?
<abu[7]>
The traversal as very fast
<abu[7]>
The conditions
<abu[7]>
"the exe in its CADR"
<beneroth>
ah, when 'lst cases are used
<beneroth>
T
<beneroth>
ah right, the example in the reference is good
<beneroth>
multiple cases with the same key
<abu[7]>
yes
<beneroth>
I somehow never used that
<abu[7]>
A long example is in vip
<beneroth>
in many cases I have no CDDR because the CADR needs to decide next state
<abu[7]>
(vi 'vip~markup)
<beneroth>
I see, good example with multiple cases with the same key
<abu[7]>
multiple cases are the normal case
<abu[7]>
T
<beneroth>
thanks! I'll check if I can improve my code by using multiple cases
<abu[7]>
ok 👍
<beneroth>
(state) is very elegant
<abu[7]>
It is a whole concept in a single function
neuroevolutus has joined #picolisp
<abu[7]>
like 'fifo' too
<beneroth>
yes
<beneroth>
btw. recently I hade a case where would wanted to have queue1
<abu[7]>
I see
neuroevolutus has quit [Client Quit]
<abu[7]>
yeah
<beneroth>
but rare case. push1 and flip if order matters is obviously better
<abu[7]>
and queue is a bit inefficient anyway
<beneroth>
T
<abu[7]>
so a member or memq is ok
<beneroth>
T
<beneroth>
abu[7], the keys don't matter after reading, right? so they could easily a bit longer and descriptive ?
<beneroth>
*be
<abu[7]>
Yes, '==' checks iirc
<abu[7]>
aka 'casq'
<beneroth>
perfect
abu[7] has left #picolisp [#picolisp]
abu[7] has joined #picolisp
theruran has quit [Quit: Connection closed for inactivity]
<beneroth>
abu[7], using (state ...) with multiple cases for same key - made the code shorter and more readable 👍👍👍
<abu[7]>
Great :)
<beneroth>
I kinda overlooked that in the past >.<
<beneroth>
thanks for the reminder :)
<abu[7]>
☺
<beneroth>
saves some if's and cond's
<beneroth>
abu[7], how expensive is throw/catch (symbols for non-local jump, not errors) ?
<abu[7]>
It is indeed a bit expensive, due to enwironment handling
<beneroth>
I guess it isn't really a difference if its catch of a 'sym or error-handling?
<beneroth>
the expensive part is happening when setting up (catch) environment? or when throw'ing?
<abu[7]>
both
<beneroth>
catch -> additional bookkeeping (memory), right ?
<abu[7]>
catch saves the env
<abu[7]>
yes
<beneroth>
I think this answers my questions for now, thank you!
<abu[7]>
ok :)
<abu[7]>
: (bench (do 999999 (catch 'a (throw 'a))))
<abu[7]>
0.245 sec
<abu[7]>
-> NIL
<abu[7]>
No big thing :)
<abu[7]>
Micosecs
<beneroth>
yeah
<abu[7]>
245 nanose6
<beneroth>
I guess insofar as catch/throw implementations go, picolisp is a lightweight one, even with the dynamic binding
<abu[7]>
Probably, yes
<abu[7]>
Binding does not matter here though
<beneroth>
because it doesn't need additional context saving for catch, just throwing away the environments we're thrown out from?
<abu[7]>
No vars involved
<beneroth>
right
<abu[7]>
(catch 'a (let A 7 (throw 'a)))
<abu[7]>
Then A is restored
<abu[7]>
(catch 'a (in "file" (throw 'a)))
<abu[7]>
does a 'close'
<beneroth>
yeah
<abu[7]>
so it depends on the job
<abu[7]>
A big square root takes longer :)
<abu[7]>
: (bench (do 999999 (sqrt 100000000000000000000)))