ChanServ changed the topic of #picolisp to: PicoLisp language | Channel Log: https://irclog.whitequark.org/picolisp/ | Check also http://www.picolisp.com for more information
<rick42> CORDIC: thanks
<rick42> i just pushed on the list and looked up the values "backwards". :D
<rick42> works fine that way
orivej has joined #picolisp
ubLIX has quit [Quit: ubLIX]
<Regenaxer> Yeah, 'append' is double-expensive, because it traverses AND copies all but the first list(s)
<Regenaxer> 'conc' traverses till the last cell, but does not copy
rob_w has joined #picolisp
orivej has quit [Ping timeout: 258 seconds]
_whitelogger has joined #picolisp
ubLIX has joined #picolisp
rob_w has quit [Remote host closed the connection]
aw- has quit [*.net *.split]
DerGuteMoritz has quit [*.net *.split]
DerGuteMoritz has joined #picolisp
aw- has joined #picolisp
ubLIX has quit [Ping timeout: 268 seconds]
ubLXI has joined #picolisp
ubLXI has quit [Ping timeout: 252 seconds]
ubLIX has joined #picolisp
<rick42> Regenaxer: thanks!
<Regenaxer> Hi rick42!
<rick42> Regenaxer: how does `rot` work? i ended up using that too.
<Regenaxer> btw, 0 and 1 are usually quite useless in pil, just normal numbers
<rick42> Hi
<Regenaxer> 'rot' is destructive
<Regenaxer> It moves the CARs in the cells
<rick42> so there is not shifting of one value from one place to another. the cells remain the same
<rick42> oh it does?
<rick42> from one cell to another?
<Regenaxer> right
<rick42> ok
<rick42> my list is not too long so that is ok. actually, i'm very happy with the performance
<Regenaxer> good :)
<Regenaxer> Lists of length less than 100 are usually faster traversed than moving from one primitive to the next
<Regenaxer> So for speed it is more important to have short programs
<Regenaxer> eg (if (not X) is a lot worse than (ifn X
<Regenaxer> 'not' has a function call overhead
<rick42> on another note, i was tempted to answer the ML on the Lens issue, but decided not to. it does not seem to fit in with what pil does and its idioms, and i didn't want to get involved in a discussion which i determined would have borne no fruit for anybody.
<rick42> ah yes
<rick42> good "rule of thumb" to have (if one doesn't have time to look under the hood (of picolisp))
<Regenaxer> I'm impressed by the lens program, but can't cogment it as I don't understand it
<Regenaxer> But it is written very well
<Regenaxer> and *lots* of comments!!!
<Regenaxer> rick42, do you understand the lens concept?
<rick42> it's a great idea for accessing and changing "persistent" data structures (i.e., where you don't alter parts of the structure as much as render another copy of the original with the mods (but the common elements are still shared)). this situation does not prevail much (if at all) in pil programming AFAIK
ubLIX has quit [Quit: ubLIX]
<rick42> yes, for instance, clojure also has such a thing
<rick42> (as well as haskell, mentioned by the poster)
<Regenaxer> Something like what 'append' does?
<rick42> yes
<Regenaxer> or 'delete' and all those classical functions
<Regenaxer> yes, very important sometimes
<rick42> in pil there is more control of course. you can do this manually
<rick42> perhaps i'll go back to the lens project and read it again.
<Regenaxer> true, but in a complicated setup like the database the concept might be useful
<Regenaxer> Would make a different DB, more like a Git repo
<beneroth> good evening
<beneroth> I've a similar opinion as rick42 towards the lens thing - impressing thing, but only partially handy in pil, I currently believe
alexshendi has joined #picolisp
<beneroth> Regenaxer, you liked the implementation? much is list building and then using (eval), so I believe there are better ways, no?
<beneroth> lens comes from Haskell
<Regenaxer> Not sure in this case. I did not deeply analyze
<beneroth> the point is to have something like picolisps (get) for chained access to nested list/properties - but also for writting (or writting a copy) instead of just fetching the data as with (get)
<Regenaxer> Sometimes 'eval' of a built list is needed
<beneroth> T
<Regenaxer> He seems bo build functions, so it is ok
<beneroth> it looked to me like (apply) could be used, and maybe conc, but I'm not an expert on this yet :)
<beneroth> yeah I use that list/func build mechanism in my code too. though I guess I can optimize it with apply/conc
<Regenaxer> He used such things too, like 'pass'
<beneroth> that's advanced pil knowledge :)
<beneroth> good!
<Regenaxer> Usually I build funs with 'curry'
<Regenaxer> which is a froitend to 'fill' and thus list building
<beneroth> yep, curry is nice. I just recently started using it.
<Regenaxer> frontend
<beneroth> ah, so it's just fill + local scoping
<Regenaxer> yes, 'job'
<Regenaxer> 'curry' does also explicit consing: (cons 'job (lit (env @)) (fill "Z" ...
<rick42> guys, question: (set Place 42) will "assign" the value 42 to the CAR of cell at the "address" Place. but how could you change the CDR of the cell instead? thanks (i must be missing something; seems like an easy question ...)
<rick42> btw hi beneroth :)
<beneroth> hey rick42 !
<beneroth> pil stores values in the CAR
<Regenaxer> yes, 'con'
<rick42> ah thanks i will read about it in the ref
<beneroth> nice you find more time/opportunity to work with pil, rick42 :)
<Regenaxer> indeed! :N
<Regenaxer> ;)
<beneroth> only good if the core of the community = aka (my definition) people active here AND active with pil, grows a bit more :)
orivej has joined #picolisp
<rick42> beneroth: yes. last night i did a writeup of the "recursive staircase" problem; solution in pil. i learned a lot about may weaknesses in pil. the write up shows how I went from a recursive solution and why it was necessary to turn it into a loop (if you didn't start there) and how the code morphed into more idiomatic pil. hahaha. so it shows the "warts" :)
<rick42> a more experience pil programmer would have written my final version as his/her first version -- and it may have even been better lol
<beneroth> the way is important, if the way is proper, it leads to the right goal automatically :)
<rick42> T
<Regenaxer> What was the problem with the recursive version?
<rick42> it was blowing up the call stack
<Regenaxer> Ah, yeah
<rick42> so one couldn't use large values of N (an input). i know that doesn't say much; however, the recursive staircase problem is a *generalized* "Fibonacci* function in disguise :) so, like a recursive Fibonacci solution, looping is the way to go -- so you can compute for instance the 10000th term very quickly
<Regenaxer> Did you try '-s unlimited' too?
<rick42> no i didn't
<rick42> i wanted it to work for "arbitrarily alarge" input
<rick42> s/alarge/large/
<Regenaxer> Bigger than memory?
<rick42> sure :)
<Regenaxer> So the non-recursive version builds no data-structure?
<rick42> if not for one input, i could have just increased it my a few orders of magnitude to make sure it broke :)
<Regenaxer> Then recursion is indeed not wise, if it is used *only* for flow control
<rick42> the non-recursive solution needs to "remember" the computation of some previous terms (in the sequence). for instance, Fibonacci only needs to rememeber the 2 previous terms. hence, the space requirement is constant (O(1))
<rick42> T
<Regenaxer> Normally you keep states in the stack during recursion
<Regenaxer> ah, ok, but then recursion does the same
<Regenaxer> with unlimited stack
<Regenaxer> you save more though, also return addresses
<rick42> sure, but it's using space that it doesn't need
<Regenaxer> But basically you are always limited by memory
<Regenaxer> heap or stack
<Regenaxer> recursion is just more wasteful
<rick42> for instance the final version of that program remembers that last J previous terms each iteration. so, that's where I used `rot`: so I would only keep the last J. i used `rot` like right shift where the "farthest" element "fell off" the end (because I didn't need it anymore)
<rick42> yes
<Regenaxer> I see, cool
<rick42> (set (rot previous) value-of-newest-term)
<rick42> :)
<Regenaxer> I use 'push' and 'con' in such cases
<rick42> ah. is there a "better" way? curious.
<Regenaxer> To limit a list I do (and Lst 99) (con @))
<Regenaxer> Not necessarily better
<Regenaxer> I push to Lst
<rick42> i see
<Regenaxer> then the above discard the olest
<Regenaxer> I use rot too
<rick42> neat
<Regenaxer> eg in 'select' for a last-recently used scheme
<Regenaxer> Usually I rotate the first N cells only
<Regenaxer> (rot Lst N)
<Regenaxer> : (setq L (1 2 3 4 5))
<Regenaxer> -> (1 2 3 4 5)
<rick42> the very nice thing about picolisp is the collection of useful primitives. i think that is taking me the longest time to "get". it's unlike other lisps. not a bad things because the other lisps haven't taken the time to solve some of the programming pain points as you have
<Regenaxer> : (rot L 3)
<Regenaxer> -> (3 1 2 4 5)
<rick42> yes, i read the in ref. very nice
<rick42> last night :)
<Regenaxer> Great :)
<rick42> every time i need to programming in pil, i go "spelunking" into ref :)
<Regenaxer> haha, me too
<beneroth> :)
<Regenaxer> Too much gc in the brain
<rick42> lolol
<beneroth> T
<beneroth> bbl
alexshendi has quit [Read error: Connection reset by peer]
<Regenaxer> 👍☺
<beneroth> ?
<Regenaxer> yes, I can see
<Regenaxer> (reload browser)
ubLIX has joined #picolisp
<rick42> w3m >> lynx
ubLIX has quit [Quit: ubLIX]
miskatonic has joined #picolisp
miskatonic has quit [Quit: ERC (IRC client for Emacs 24.5.1)]