chexum has quit [Remote host closed the connection]
chexum has joined #picolisp
chexum_ has joined #picolisp
chexum has quit [Ping timeout: 268 seconds]
chexum_ has quit [Quit: No Ping reply in 180 seconds.]
chexum has joined #picolisp
chexum has quit [Write error: Connection reset by peer]
chexum has joined #picolisp
<beneroth>
"I can share my perspective from Clojure, where I tend to think in data. A program is a sequence of immutable functions"
<beneroth>
out of context, but I just found it funny to read "think in data" and "immutable functions" in one sequence...
<abu[m]>
Indeed. At least no mention at all of the equivalence of code and data.
<beneroth>
ah, even in the original context it was a mistype:
<beneroth>
"I meant 'pure' functions which take and return immutable data structures."
<beneroth>
not to bully clojure, but it looks somewhat funny and inconsequential from picolisp pov
<abu[m]>
At least the pil pov does not make so much fuzz about immutability
<beneroth>
abu[m], I get the feeling that people forgot about this, even the lispers. When it is the one single feature of lisp which makes it elegance but also demands the list-syntax with parenthesis
<beneroth>
yeah
<abu[m]>
right
<beneroth>
nothing is immutable. even more so when our whole reality is just one big fight to get enough negative-entropy to have some stable structures for a while.
chexum has quit [Remote host closed the connection]
chexum has joined #picolisp
calle_ has quit [Ping timeout: 272 seconds]
calle_ has joined #picolisp
calle_ has quit [Ping timeout: 252 seconds]
chexum has quit [Ping timeout: 268 seconds]
chexum has joined #picolisp
<abu[m]>
Wow! Found and fixed a real nasty bug in 'extra'
<abu[m]>
It turned up in the #picolisp channel on Matrix, happened only in Android on some devices, but generally could happen anywhere
<tankf33der>
Never user before
<tankf33der>
testing anyway
<abu[m]>
Surely used, but the bug did never show up in Debian
<abu[m]>
It is only if the heap is located at very high memory addresses, so that pointers may have the highest bit set (i.e. negative 64-bit numbers)
<abu[m]>
Only 'extra' I hope
<abu[m]>
But 'extra' is used very heavily in the DB- and E/R-classes, so it crashes immediately
<tankf33der>
Passed.
<abu[m]>
Thanks!
<beneroth>
abu[m], you think it's also in pil64 ?
<abu[m]>
No, pil64 was correct, it used the CPU flags to communicate back to the caller
<beneroth>
extra is pretty fundamental to pil OOP, but I guess it takes a lot of weird randomness to trigger the bug
<beneroth>
ah, I see. thanks!
<abu[m]>
pil21 used the sign, and that's fatal
<abu[m]>
Not so much randomness, more how the OS allocates process memory at runtime
<beneroth>
T
<abu[m]>
Unix traditionally uses lower addresses for heap and higher ones for stack
<abu[m]>
But in Android everything is done differently 😞
<beneroth>
the extra mechanism is one of your original concepts, not inspired by something existing, correct? the ordered parenting makes pil OOP pretty outstanding compared to all other OOP systems I know off, and also makes it the most elegant.
<abu[m]>
Yes, 'extra' is pil-only
<beneroth>
yeah android cannot really be considered a linux distro
<abu[m]>
true
<abu[m]>
Still it was stupid that I used such values
<beneroth>
abu[m], I'd guess you just used list as container for the multipe parents, and the ordered priority search was just the logical emergent thing to follow?
<abu[m]>
'extra' returned a pointer if success, or 0 or -1 for failure
<abu[m]>
yes, it was naturally following
<abu[m]>
pil64 returned the pointer and some flags, or just flags for failure
<abu[m]>
Now, 'extra' uses 0 and 1 for failure, and compares (> X 1) to detect a pointer (no more sign check)
<abu[m]>
I think it is safe now ☺
<beneroth>
good! thumps up :D
<beneroth>
I find that OOP mechanism just brilliant. Solves the diamond problem for real, whereas Java/C# just restrict the programmer and still don't solve it. C++ at least gives the possibility of control there, but in such a bad way that bad stuff happens accidentally very easily.
<abu[m]>
Interesting
<beneroth>
for me the extra mechanism puts the focus in OOP on dynamic message handling, which is in my understanding the hole point of OOP as intended by Alan Kay et al. But most OOP implementation focus primarily on the encapsulation which gives quite different results.
<abu[m]>
Exactly
<abu[m]>
A static view
<abu[m]>
The terminology shows it. Such systems talk more of classes than o f objects
<abu[m]>
the terms are messed up. "I have a class X here" when they mean "an object X"
<abu[m]>
the concepts
<beneroth>
T
<beneroth>
well one benefit this focus on encapsulation has, it allows to work on a single big piece of software with many people without having people to trust each other - the restriction-based OOP implementations make this managable.
<beneroth>
*manageable
<beneroth>
but I would think the whole idea of designing software with huge teams is crap. ("all good systems were designed by 1-2 people" etc.)
<abu[m]>
indeed
<abu[m]>
and open systems are also manageable
<abu[m]>
See the Linux kernel
<beneroth>
I suspect the whole "immutable data" in functional programming comes from the same corner. Because if a programmer has a reasonable oversight and understanding of the software they are working on, than they should not need technically enforced immutability - just don't change things where you don't want to allow it.
<abu[m]>
Perhaps, though the main objective in my understanding are threads
<beneroth>
that doesn't mean a programming language/paradigm should allow easy mistakes there....
<beneroth>
yeah, but threads are about shared memory. what worth is it if its read-only for all? the immutability is not about truly making it immutable, but to hide the consciousness locking signaling
<beneroth>
which I guess makes it easier, but then again I would think in many cases adds a lot of unnecessary overhead
<abu[m]>
right
<beneroth>
we manage shared concurrent data access in databases for a long time, same methodologies could be used in RAM handling
<abu[m]>
Sometimes it just makes things easier. Using 'append' instead of 'conc'. But I want to decide that.
<beneroth>
T
<beneroth>
maybe we're outliers in our ability to apply self-discipline. it's possible.
<abu[m]>
I cannot judge Clojure etc., but at least in PicoLisp it is very easy to keep it safe
<abu[m]>
a simple rule, in that you can say a data item is truely private (typically just created) and thus should be modified destructively
<beneroth>
but how much the apparent inability for that in other software creators is inert (dis)ability and how much caused by circumstances, "code bureaucracy" (as in this permission/encapsulating OOP systems) or simply training and habit, that seems not so obvious to me
<abu[m]>
Mosty hiding such details from the programmer to "protect" him
<beneroth>
protect from whom? themselves and their lack of knowledge or discipline.
<beneroth>
well discipline, because if they cannot increase knowledge themselves they can hardly ever become good programmers in the first place...
<abu[m]>
yep, mainly from himself, so he does not really need to understand