beneroth changed the topic of #picolisp to: PicoLisp language | The scalpel of software development | Channel Log: https://libera.irclog.whitequark.org/picolisp | Check www.picolisp.com for more information
lagash has quit [Ping timeout: 252 seconds]
lagash has joined #picolisp
<geri> beneroth: (a . (b . (c . NIL))) == [a, [b, [c, NIL]]]
<geri> same exact structure made of arrays instead of pairs
rob_w has joined #picolisp
cpli has quit [Remote host closed the connection]
casaca has quit [Remote host closed the connection]
payphone has quit [Remote host closed the connection]
payphone has joined #picolisp
casaca has joined #picolisp
cpli has joined #picolisp
bjorkintosh has quit [Ping timeout: 260 seconds]
rob_w has quit [Ping timeout: 268 seconds]
bjorkintosh has joined #picolisp
bjorkintosh has joined #picolisp
<geri> honestly its weird linked lists seem to be seldom used
<geri> except for lisps and some data structures like queues
<abu[7]> Yeah, most language designers worry more about efficiency than about expressive power
<geri> i mean, even if that - linked lists make a lot of sense in quite a few situations, no?
<abu[7]> Also Lisp implementors, worrying too muhc about compilation
<abu[7]> The make sense for *everything*
<geri> i mean
<geri> you can use them for anything, but for example if you need hash tables they dont make sense to use for storage?
<geri> often used for the bucket though
<abu[7]> You make a tree then
<geri> kinda tempted to implement something like tries in picolisp now
<geri> :D
<abu[7]> Pil is full of trees
<abu[7]> namespaces, idx, enum
<abu[7]> with enum you can index numerically
<abu[7]> like into an array
<abu[7]> but it is a tree
<geri> does it mean i could implement hash maps with enum as data storage instead of an array?
<abu[7]> I don't think so
<geri> why not?
<abu[7]> Depends
<geri> it wont be constant retrieval time, but itll be pretty good i think all things considered
<abu[7]> A direct tree is better
<abu[7]> why hash?
<geri> wdym by direct tree
<abu[7]> Hashing takes time too
<geri> lets say i just have a huge amount of key/value pairs
<geri> what tree structure do i use for that
<abu[7]> Until you calculated the hath you have traversed the tree
<abu[7]> I would use 'idx'
<abu[7]> Or a DB which uses B-Trees
<abu[7]> (store ...) and (fetch ..)
<geri> abu[7]: how do you search for a particular key in a tree though?
<geri> if its by walking each and every branch until you find what you need it's probably not a good idea
<abu[7]> (fetch Tree Key)
<geri> if you have 1k+ keys or something like that
<abu[7]> Look at https://picolisp.com/osm
<abu[7]> About 400 million objects
<abu[7]> All indexed by several keys
<geri> so that's using b-trees?
<abu[7]> Accessing a node fetches a few thousand objects in the fraction of a second
<abu[7]> Yes, B-Trees
<geri> okay, pretty epic
<geri> only need 2 pointers to represent about anything :D
<abu[7]> Try the above link, user and pw is "osm"
<geri> that's pretty incredible honestly
<abu[7]> Each line on the map connects two objects
<abu[7]> nodes and ways
<abu[7]> 340,261,042 Nodes
<abu[7]> es
<abu[7]> oops
<abu[7]> and you find each of them immediately
<abu[7]> Try that with a hashmap ;)
<geri> haha
<geri> yeah i guess
<geri> its pretty amazing how much you can do with just an object that's 2 pointers
<abu[7]> True
<geri> only downside is memory usage i guess?
<abu[7]> Not so much
<abu[7]> cells don't fragment memory
<geri> yeah, that's the upside of nothing but cells
<geri> but chopped symbols for example take a ton of space compared to even symbol names
<geri> and thats still more than just an array of characters
<abu[7]> This is again worrying too early
<geri> yeah
<abu[7]> There are extreme cases like Vip
<abu[7]> a list of list of chars
<abu[7]> but still no problem in most cases
<abu[7]> only *very* big files get slow
<geri> yeah
<geri> how big is very big?
<abu[7]> Several MiB I think
<abu[7]> @src/base.ll is at the border
<geri> so like 1M characters, ~8 bytes per char?
<geri> 16
<abu[7]> @src/base.ll has 3.3 MiB
<abu[7]> Try it in Vip
<abu[7]> A bit slow
<abu[7]> Especially some things like searching backwards
<abu[7]> But could be implemented more efficiently
<abu[7]> at the loss of simplicity
<geri> 3450089 characters
<geri> a transient symbol is 16 bytes i think
<abu[7]> T
<geri> 55201424 bytes
<geri> so 55 mb of ram?
<abu[7]> More
<abu[7]> Try vi @src/base.ll then : (heap)
<abu[7]> Gives 111
<abu[7]> ie. MiB
<abu[7]> But why do you worry so much?
<bjorkintosh> that's a lot on a 486.
<abu[7]> This is not normal Vip usage, base.ll is an intermediate file
<bjorkintosh> almost unimaginable, even.
<geri> its inconvinient but i dont really worry much
<abu[7]> It is even more a lot on a Z80
* bjorkintosh laughs in 32Gigs of ram and counting ...
<geri> long files slow emacs down to a crawl
<geri> too
<bjorkintosh> max out your RAM folks!
<bjorkintosh> don't be stingy.
<geri> long lines especially
<bjorkintosh> it's not worth the hassle not to.
<geri> i had 8 gigs for a long time on this machine and it was fine
<geri> now 16
<bjorkintosh> oh for me it's the principle of the thing. if the machine I have can do 64 gigs, that's what I'm going to get.
<bjorkintosh> it's cheap enough.
<geri> what for though
<bjorkintosh> <bjorkintosh> it's cheap enough.
<geri> i never got to use swap even with 8 gigs on linux
<bjorkintosh> so why not?
<geri> if its not used its wasted money
<geri> even if its relatively cheap
<bjorkintosh> don't care.
<bjorkintosh> it's cheap enough.
<geri> someone's got cash to burn, i see :D
<bjorkintosh> no. I don't splurge on GPUs.
<bjorkintosh> those are costly.
<bjorkintosh> compared to that? Ram is ridiculously cheap.
<geri> i use same laptop i used since like 2018
<geri> and im happy with it
<bjorkintosh> cool.
<geri> xd
<bjorkintosh> mine is from 2016.
<bjorkintosh> 32 Gigs of RAM and still feels performant.
<bjorkintosh> <-- this old machine.
<bjorkintosh> and I bought it used, mind you.
<geri> haha
<geri> sounds about right
<geri> i actually broke my touchpad when checking if i can switch to an ssd
<geri> then upgraded ram when wanted to play elden ring
<bjorkintosh> thinkpad w520. released 2011.
<bjorkintosh> so this laptop is not so young.
<geri> yeahhh
<bjorkintosh> if I can max it out, I always do. there's no good reason not to. unless it's not affordable.
<geri> abu[7]: is there a way to get a subtype of a list?
<geri> like if its a plist, an alist or anything else
<geri> idx tree, enum
<abu[7]> By analyzing it?
<geri> that's what i think you should do if you need the ability
<abu[7]> No formal difference
<geri> yeah
<abu[7]> Lists is too low level
<abu[7]> I would go with OOP
<geri> cons cells even
<abu[7]> What use case do you think of?
<geri> lists are built on top of em just how plists and alists are
<geri> im just thinking
<abu[7]> ok
<geri> if you have some code that could return a list or an alist or something else, how do you know how to get data out of it
<geri> if you do have formal difference you can just run the predicate function to know
<abu[7]> You can cons a token
<abu[7]> But usually you know from context
<geri> (list a b c), (plist a 5 b 6), (alist (a . 5) (b . 6))?
<abu[7]> ugly though
<abu[7]> Namespaces in Pil do this
<abu[7]> a tilde is in the CAR
<abu[7]> But it is a special case
<abu[7]> Must go, bbl
<geri> later
<geri> yeah it is ugly, but pretty reliable i think
<geri> same as my array/object thing in json parser
<abu[7]> ret
<abu[7]> yess