<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.