07:17 <Regenaxer> razzy: I think my definition from yesterday was right. Perhaps add "side effect"

07:18 <Regenaxer> So a destructive operation is:

07:18 <Regenaxer> Modifying *list* structures as a *side* effect

09:06 <razzy> Regenaxer: I do not really care about names. As long as we have other name for all "mutating" operations I can agree with you. I do not think your idea is major oppinion of general programmers, but majority is often wrong :).

09:08 <razzy> Side effect is good definition of your idea

09:08 <Regenaxer> I think my definition is like that of comon lisp and emacs lisp

09:08 <Regenaxer> But which operations are *not* mutating something??

09:15 <razzy> Regenaxer: example would be (reverse) (car)

09:15 <Regenaxer> ok, 'car' yes. But 'reverse' is modifying

09:16 <Regenaxer> modifies heap and stack

09:16 <razzy> I am not avare

09:16 <Regenaxer> it can even trigger garbage collection with *lots* of modifications ;)

09:17 <Regenaxer> So you mean "modifies user-visible data"

09:17 <razzy> after it is done,symbol has same value.

09:18 <Regenaxer> Anyway, functions which modify something need no special name

09:18 <Regenaxer> not critical

09:18 <razzy> It would help me.

09:18 <Regenaxer> (reverse) does not involve any symbol

09:18 <Regenaxer> What would it help?

09:19 <razzy> I cannot talk for others.

09:19 <Regenaxer> all function calls, 'let', 'for' etc

09:19 <Regenaxer> all modify symbol values

09:19 <tankf33der> https://envs.sh/Op.l

09:19 <Regenaxer> Hi tankf33der!

09:19 <tankf33der> Simplest code to demo cut

09:19 <tankf33der> hi all

09:20 <Regenaxer> What does it demo?

09:20 <Regenaxer> that the value of L changed?

09:21 <tankf33der> and how it changed

09:21 <Regenaxer> yeah

09:21 <Regenaxer> set to the cdr of the value

09:22 <Regenaxer> So 'cut' is not destructive

09:22 <Regenaxer> it does not change a list

09:23 <Regenaxer> "Modifying *list* structures as a *side* effect"

09:23 <Regenaxer> both must be given

09:23 <Regenaxer> modifying a symbol value is not destructive

09:25 <Regenaxer> An (cut 2 (cdr (1 (2 3 4 5 6) 7))) -> (2 3) also is not destructive, because it is not a side effect

09:25 <Regenaxer> it is the desired effect

09:28 <razzy> Regenaxer: I will mark mutating functions on my own, no big problem.

09:28 <Regenaxer> good

09:28 <razzy> tankf33der: I like the examle, makes it more clear to me.

09:28 <Regenaxer> Then better mark non-mutating functions, no?

09:29 <razzy> yes, that what i meant

09:29 <Regenaxer> yes, looking at the memory pointer with 'adr' is the ultimate proof

09:35 <tankf33der> razzy: check this out

09:35 <tankf33der> https://git.envs.net/mpech/pil21-tests/raw/branch/master/double.l

09:35 <tankf33der> If you understand this then you safe

09:37 <Regenaxer> oh, I faintly remember

09:57 <razzy> tankf33der: yes, I wanted that example for a long time to build my skiplist :) thank you

10:27 <razzy> tankf33der: example not really working. Lst is NIL. I think i know what doubly linked list means in theory

10:28 <razzy> ah

10:42 <razzy> tankf33der: umm, example seems broken to me. I am not safe :)

10:54 <tankf33der> razzy: sure, this is the most advanced pil code ever.

11:00 <razzy> tankf33der: (setq *DLst (2list 'was 'it 'a 'cat 'I 'saw)) gives segmentation fault

11:01 <razzy> which is not what i expected as example?

19:32 <razzy> what is EOF overrun error?

19:34 <razzy> solved

20:15 <Regenaxer> good :)

20:23 <razzy> I am able to iterate in picolisp towards a working SW. I rarely know exactly why it is working the way it is working :D.

20:44 <Regenaxer> Just go on! :)

20:44 <Regenaxer> Good night!

21:49 <beneroth> razzy, EOF overrun is nearly always missing closing parenthesis

21:50 <beneroth> literally "run over End-of-File when EOF was not yet to be expected"