<geri>
there's a picolisp implementation of mal too btw
<geri>
just making it into fexprs instead of everything gets evaluated + special forms and whatnot is not difficult, but doing other magic is
<abu[7]>
Impressive projct!
<geri>
ikr :D
<geri>
its fun for learning
Iacob has quit [Quit: IRCNow and Forever!]
Iacob has joined #picolisp
bjorkint0sh has joined #picolisp
bjorkintosh has quit [Ping timeout: 256 seconds]
<geri>
do you know, historically, did setq come to be before quote became a reader macro?
<abu[7]>
I'll answer later, currently in a meeting
<geri>
hope its not boring
<abu[7]>
No ☺
<geri>
glad!
<abu[7]>
Done
<geri>
wb?
<geri>
(very late on my side properly :D)
<abu[7]>
Oh
<abu[7]>
quote, cond and setq were "special" functions from early on I think. No idea when the ' read macro appeared
<geri>
im just thinking that it kinda makes little sense now that ' is a thing
<geri>
i.e. (set 'x 1) and (setq x 1) have same amount of characters
<abu[7]>
True
<geri>
and quote is on default keyboard layer too
<geri>
so its not even easier to type
<abu[7]>
In an interpreter setq is faster
<geri>
because you dont gotta eval first argument?
<abu[7]>
T
<geri>
okay, fair
<abu[7]>
A function call
<geri>
i was so impressed how easy eval is in a fexp language
<geri>
compared to having a bunch of special forms
<abu[7]>
yeah
<abu[7]>
: (bench (do 9999999 (setq A 7)))
<abu[7]>
0.101 vs. 0.188 sec
<geri>
although i hadnt managed to figure out how to do set/setq yet because in mal def! is special so the environment doesn't need to be passed - it's part of eval
<geri>
amazing performance difference :D
<geri>
0.094 vs 0.149 sec here
<geri>
your phone is just slightly weaker than my laptop xd
<abu[7]>
:)
<abu[7]>
it is a Pixel Fold
<abu[7]>
new since last week
<geri>
sweet
<geri>
do you do custom roms?
<abu[7]>
My old OnePlus was only half that speed
<geri>
just curious
<abu[7]>
I did (CyanogenMod), but not currently
<abu[7]>
But I did not register it at Google
<geri>
i think it's been replaced with LineageOS
<geri>
good!
<abu[7]>
Yes LineageOS now
<geri>
they dont deserve even more data
<abu[7]>
I use F-Droid and Aurora Store
<geri>
i use fdroid too
<geri>
although im not as pure
<geri>
😢
<abu[7]>
Aurora is cool
<abu[7]>
an anonymous access to PlayStore
<geri>
is it just a proxy?
<abu[7]>
Yes, as I understand it
<abu[7]>
it is in F-Droid
<geri>
oh thats nice
<geri>
also ive been wondering, how's performance on alists compared to hash tables?
<geri>
as for length let's just say "big and small" :D
<abu[7]>
In any case, these are just assoc lists and not hashss
<geri>
so linear search time...
<abu[7]>
T
<abu[7]>
Better is 'idx' on 'enum' for larger data
<geri>
those were tree functions iirc?
<abu[7]>
Yep
<geri>
lists are so versatile :D
<abu[7]>
indeed :)
<geri>
how'd you come up with using fexprs/fsubrs for picolisp?
<abu[7]>
I don't remember exactly. My first Lisps still evaluated the args and then called the built-ins, but I noticed this is unnecessary if you don't need to support compiled code
<geri>
and it saves time sometimes too, like with set vs setq
<geri>
(also-also, the entry in table of contents is called a different thing than the title it points to)
<abu[7]>
Thanks! I'll fix it
<geri>
oh hey, im almost a contributor now :D
<abu[7]>
YAY ☺
<geri>
haha
<beneroth>
interesting :)
<beneroth>
abu[7], how did you come up with having the datatype attached to the value and not variable (as most languages)? is that a general lisp thing?
<beneroth>
I find this is also a quite subtle but important difference
<abu[7]>
It is a gereral lisp feature
<beneroth>
many people like to go on about type safety on and on, but then they often only have type on the variables, not on the values themselves
<beneroth>
ok
<beneroth>
from a type safety perspective, I find it doesn't actually make much sense to have types on variables without having them on values. the values should be more important, all in all.
<beneroth>
then again this comes from compiling, C/C++ etc. have no datatypes after compiling.
<abu[7]>
Right. Static thinking and checking
<beneroth>
yeah. can't fix this with pseudo-agile project management if the language doesn't support dynamic programming :)
<beneroth>
it had very good explanation of the nature of paradigms in general, and functional in particular
<beneroth>
he observed that paradigms in programming are restrictions (to enforce discipline)
<beneroth>
he basically defines OOP as "enforce working without function pointers by having polymorphisms (vtable in C++) instead" - not exactly the Alan Key definition, but quite on point, kinda
<beneroth>
structural programming = no goto, to have the program easier understandable and proofable
<beneroth>
so paradigms are restrictions to enforce programmer behaviour
<abu[7]>
I always hated restrictions
<beneroth>
and functional he saw essentially as "way to get over the Moore's law breakdown", aka we seem not able to increase CPU speed but parallelizing more. Functional he defines strictly as "not allowing assignments", which of course removes all the issues with shared memory and concurrent access
<abu[7]>
I would not tie "functional" with "immutability" so much
<beneroth>
he also pointed out that the prevalence of textual programming (vs. graphical programming language) might well come from the fact that time is 1-dimensional sequence, so algorithms are 1-dimensional step-by-step, so textual lends itself much more to it (line by line) instead of the 2D (or more dimensions) of graphical programming
<beneroth>
abu[7]> I would not tie "functional" with "immutability" so much
<beneroth>
me neither
<beneroth>
but its often done
<abu[7]>
T
<beneroth>
I think his observation are quite on point, found it refreshing to have it so boiled down to the essentials.
<beneroth>
I suspect he is indeed right about the text vs. visual thing
<beneroth>
<abu[7]> I always hated restrictions
<beneroth>
same
<beneroth>
I hate the datatyping in C#, it's more of a hindrance than help to me. half of the code ends up doing conversations of a sort.
<beneroth>
programmers should be able to be self-disciplined
<beneroth>
we are
<beneroth>
but then again most are not very good in it.
<abu[7]>
sadly yes
<geri>
btw, is it true that assembly is statically typed?
<geri>
what
<geri>
dynamically typed*
<abu[7]>
It is not typed at all
<geri>
thats like even less typing than dynamic
<geri>
:D
<abu[7]>
Types are in the instructions
<abu[7]>
☺
<geri>
had anyone created a physical pilmcu machine prototype yet?
<abu[7]>
Yes, Georg Orais ("Geo")
<geri>
are there any benchmarks?
<abu[7]>
but it turned out quite slow
<geri>
aw
<geri>
any idea why?
<abu[7]>
There is a video
<abu[7]>
I expected that. A fast CPU needs sophisticated caches etc.
<abu[7]>
Not easy with a simple gate array
<geri>
sad
<geri>
maybe one day..
<abu[7]>
T
<geri>
it's a meme but have you ever thought about using pil + as a bash replacement? :D
<abu[7]>
Not seriously. For typical shell usage Bash is more convenient.
<abu[7]>
(call "rm" "file") vs. 'rm file' :)
<bjorkint0sh>
it's one of the most awesome features of tcl.
<bjorkint0sh>
you simply type the command as is.
<abu[7]>
T
<bjorkint0sh>
but I'm sure a simple parser can be created to translate 'rm *.*' to (call "rm" "you can't be serious")
<beneroth>
for further isolation there are also namespaces, though again they work in pil a bit different than in most languages - the namespacing separates _bindings_
<abu[7]>
Namespaces define the lexical scopes of s)mbols, regandless of their values
<beneroth>
so its even possible to have multiple symbols in multiple namespaces bound to the same value
geri-- has joined #picolisp
<abu[7]>
So the scope (= visibility) of symbols is static, the values are bound dynamically
<abu[7]>
T
<geri-->
it sounds to me that dynamic binding is more powerful than lexical at a cost of being harder to reason about in select cases, how accurate would that be? :D
<abu[7]>
That is true
<abu[7]>
i.e. reason statically
<geri-->
is there a way to create a clean namespace and only import a few things into it from pico ns?
<geri-->
or shadowing
<abu[7]>
Yes
<abu[7]>
'import'
<abu[7]>
: (symbols 'foo 'pico)
<geri-->
then import and then symbols again to remove pico?
<abu[7]>
creates an empty namespace
<abu[7]>
(local) does that
<abu[7]>
(symbols (list (car (symbols)))
<abu[7]>
It isolates the first ns
<beneroth>
you declare an order of namespaces, when a symbol is read (R-step from REPL, also when loading a source code file) it is looked up in the chain of namespaces you declared, in order, first match wins.
<beneroth>
so ordering of namespaces matter, but there might be different in different source code files / different contexts
<beneroth>
s/there/they
<geri-->
first match hmm
<beneroth>
my recommendation: don't use namespaces unless you need it :)
<geri-->
that sounds sad :(
<beneroth>
the most common need is when writing library code, to hide functions and global variables which should not be used by the using code
<abu[7]>
I usem heavily
<geri-->
:D
<beneroth>
it's not sad. its there and very powerful when needed. it's like C++ templates - powerful and sometimes the right thing, but don't sprinkle it on everything
<abu[7]>
They are mandatory in PilBox apps
<beneroth>
well you can always add namespaces when using code, it doesn't need to be in it when writing it
<beneroth>
this is quite different than in most languages, but arguably more powerful
<geri-->
well in cl you can use cl-user for everything, but building the thing may or may not be painful
<geri-->
same thing in pil i guess
<abu[7]>
It is true that in Pil you should use namespaces only if you understood them
<geri-->
one say ill learn how to read the structures file...
<beneroth>
abu[7], true, that is the fundamental core of the VM
<bjorkint0sh>
33 pages.
<bjorkint0sh>
smaller than R or Scheme (60 pages)
<beneroth>
this is already with some fluff and explanations
<geri-->
common lisp is like 1k pages
<geri-->
xd
<beneroth>
abu[7], I would consider the core the parts which need re-implementing when going to another platform... so strictly the picolisp binary (which assumes a posix-environment)
<beneroth>
common lisp has a lot of cruft, hasn't it?
<beneroth>
picolisp has "pico" in the name for good reasons :)
<geri-->
it does, but a lot of cool stuff too
<geri-->
apparently the cruft was introduced so people actually use the language
<beneroth>
that sentence should not be used for marketing
<geri-->
im not a marketing person
<geri-->
:)
<beneroth>
when I started looking into Lisps, coming from C++, I saw that Common Lisp has multiple compilers and platform-dependent libraries. that repelled me, had enough of that in C/C++. so I looked further and later ended up here.
<bjorkint0sh>
the CL spec is quite old, and a lot of it rather redundant.
<bjorkint0sh>
I have no doubt that if it were today revised, it would shed a lot of the old crap.
<beneroth>
pil is older than CL.
<bjorkint0sh>
but pil is ... almost mathematical
<beneroth>
well, so is lisp...
<bjorkint0sh>
yes. lisp 1.5 :-)
<bjorkint0sh>
the 'common' squashed out the mathy bits and just turned it into a behemoth.
<beneroth>
it's a language to teach the logic of programming, not to program in. John, you did what?
<geri-->
first cltl is from 1984
<geri-->
so technically its only 4 years older than pil
<beneroth>
pil was not public back then, but I believe abu[7] already used it?
<beneroth>
though maybe more importantly is that CL didn't influence it, afaik.
<abu[7]>
I used similar versions
<abu[7]>
sorry, bbl
<beneroth>
I guess CL got also some of the "design by committee" inflictions. Though probably less bad than other languages.
<geri>
its still infinitely better than like java lets be real
<beneroth>
that's a low bar
<beneroth>
also the java problem was that some managers just run with the first research prototype implementation instead of having it done properly before releasing it.
<geri>
shrug
<geri>
some people are just like that
<bjorkint0sh>
s/people/MBAs
<bjorkint0sh>
they're the common enemy!
<geri>
xd
geri-- has quit [Quit: ERC 5.5.0.29.1 (IRC client for GNU Emacs 29.2)]
<beneroth>
T
<abu[7]>
ret
<geri>
(T T) is a crying emoji
<beneroth>
it always gets me that those people don't want to be more successful. lack of imagination and focus on short-term I guess.,
<beneroth>
geri, yeah, but T is True in picolisp
<beneroth>
or the positive infinite, the biggest number
<geri>
applying truth on truth results in tears
<geri>
)
<geri>
beneroth: what's that about success
<beneroth>
MBA types and similar morons
<geri>
eh
<geri>
success means different things to different people
<bjorkint0sh>
beneroth, since they're destroying the planet with their awful decisions, they know there's no time left for long term thinking. so they optimize short term decisions to increase the sizes of their wallet, leading to an endless loop of doom.
<beneroth>
many companies I see with such types have way more potential than they're aware themselves. most of it just goes to waste by dumb decisions
<geri>
do you mean like AI crap eating all the electricity? bjorkint0sh
<bjorkint0sh>
yes. I for one, welcome our AI overlords, whos grandfathers, interestingly enough, were all lispers.
<bjorkint0sh>
every single one of them.
<geri>
im not into commercial AI, its creepy
<beneroth>
yeah the meme is nice. not sure if Benioff really lives up to his values though xD
<beneroth>
which AI?
<beneroth>
no match for natural stupidity
<geri>
yes!
<geri>
its such a good meme
<geri>
cause its accurate
<beneroth>
not sure about the current AI hype, but I don't expect much more AI progress until we combine ML with reasoning systems like https://en.wikipedia.org/wiki/Cyc
<beneroth>
(which is again lisp based)
<beneroth>
geri, well it also fits the Club of Rome model for "business as usual". which is one of the pretty bad outlooks...
<geri>
natural stupidity being more powerful than artificial intelligence does?
<beneroth>
nah, the meme
<beneroth>
the other is my joke, afaik
<beneroth>
natural evolution just does better and more extensive testing than humans usually do
<geri>
ahaha
<geri>
gotta go, enjoy the rest of today
<beneroth>
you too :)
geri has quit [Quit: ERC 5.5.0.29.1 (IRC client for GNU Emacs 29.3)]
chexum has quit [Remote host closed the connection]
chexum has joined #picolisp
chexum_ has joined #picolisp
chexum has quit [Quit: No Ping reply in 180 seconds.]