<clacke[m]>
not exactly bitcoin but I have other casino money
<clacke[m]>
at this point if I sell I will only find out it went up again and then I will have stress over that decision
<beneroth>
:D
<beneroth>
hi clacke[m] :)
<clacke[m]>
so I'm just holding what I have and maybe it will disintegrate, maybe I will be a millionaire again (at least in JPY) by the end of the year
<clacke[m]>
I didn't burn any money I needed, it was a gamble. fiat cash flow is good.
<clacke[m]>
hi bene
<clacke[m]>
I am a happy man, I am finally working on free software
<beneroth>
yay nice. gz!
<clacke[m]>
in the casino money business actually, but that's tangential at this point
<clacke[m]>
making a build system that will power Cardano apps
<clacke[m]>
it ised to be Ethereum apps and then Ethereum Classic apps, but the build system idea is reusable outside the field
<clacke[m]>
and it's not pil, but I am using racket
<clacke[m]>
so that's nice too
<clacke[m]>
at least it has the parentheses in common
<clacke[m]>
racket is a lot of things, but the main racket language is a scheme
<clacke[m]>
it has datalog with actual datalog syntax in there too
<clacke[m]>
and also a parenthetical datalog
<beneroth>
though I also agree with the general sentiment in here, along the lines of "get stuff done, more important than language" https://news.ycombinator.com/item?id=1803351
<beneroth>
oh nice
<clacke[m]>
They are #lang datalog and #lang datalog/sexp
<clacke[m]>
There are a few variants of typed racket too, but I only know they exist, have not explored.
<beneroth>
oh so it is indeed another family, not a single thing
<beneroth>
good to know. thank you for teaching me :)
<beneroth>
My expectation (trying to build my software business on pil) is it will force to get good programmers / force the programmers to get better, which I assume/hope is a general long-term advantage (better quality, lower maintenance costs, more effective & hopefully more efficient business)
<beneroth>
dunno if this will work out
<beneroth>
just had to let go my first pil programmer for lack of drive/fire/productivity (and doesn't want to be a programmer in the long-term, that was new to me)
<beneroth>
though I guess in this specific case I would have had the same issues with any other language
<beneroth>
certainly the productivity gains using picolisp vs other non-lisp languages are substantial in my experience. less code does more. less code is easier to change.
<Regenaxer>
'((L) (mapcar pack L)) (make ... could be (make ... (link (pack ... ?
<Regenaxer>
afp bbl
<t4nkf33der>
indeed
<t4nkf33der>
:)
orivej has quit [Ping timeout: 240 seconds]
<Regenaxer>
ret
orivej has joined #picolisp
orivej has quit [Ping timeout: 240 seconds]
orivej has joined #picolisp
rudha has quit [Quit: Leaving]
orivej has quit [Ping timeout: 260 seconds]
<beneroth>
Regenaxer, whats better: A) using less (let) like (let (A 1 B 2) ...)) even when (depending on code path) part of the variables are not used? or B) multiple smaller nested (lets) like in (let A 1 ... (let B 2 ..)) ?
<beneroth>
your principle of "save memory" would say B) I think
<t4nkf33der>
i vote for A
<beneroth>
boils down to "how expensive is 'let ?"
<beneroth>
A) is likely more readable
<t4nkf33der>
because one place
<beneroth>
yeah. much better readable, unless the scope is very big
<beneroth>
the whole question does probably not matter much in practice, but I like to ask for style anyway :)
<beneroth>
thanks for your input t4nkf33der :)
<t4nkf33der>
only A then
<Regenaxer>
I would also prefer A
<beneroth>
thx
<beneroth>
its the style I use primarily
<beneroth>
in other languages I often use more local scoping, therefore the question
<beneroth>
thx
<Regenaxer>
yes, both make sense
<Regenaxer>
What I miss sometimes is a multi-var 'let?'
<Regenaxer>
(let? (A ... B ...)
<Regenaxer>
implied AND
<beneroth>
T
<Regenaxer>
Should be done
<beneroth>
I still don't use (let?) often enough. most times I go with binding to This via (with) or use (and) explicitly
<Regenaxer>
yes, 'with' is more common, and analogue
<beneroth>
I also like using This as a parameter name, thought this can confuse things when overdone
<Regenaxer>
yes, for people not used to this style
<beneroth>
e.g. in (for) and (mapcar)
<beneroth>
very handy there
<Regenaxer>
T
<beneroth>
can get confused when used in multiple nested method calls
<Regenaxer>
I was reluctant in the beginning, but then used it more and more :)
<Regenaxer>
right
<beneroth>
its just so simply and handy - and not hard to get when one overuses it, usually
<rick42>
hey!
<rick42>
o/
<Regenaxer>
Hi rick42!!
<rick42>
hi Reg! :D
<beneroth>
Regenaxer, another question: the symbols used within (state ..) and pilog queries are "scoped" / local to their expressions, right?
<rick42>
there is a case in which i would use B though
<beneroth>
expression = state, or in pilog the query tree
<beneroth>
hey rick42 o/
<rick42>
beneroth: \o
<beneroth>
rick42, certainly there are cases where B) is good. though in picolisp for that cases I often use separate functions instead of another let scope - either because the code is anyway re-used or just for readability
<Regenaxer>
In 'state' the symbols are just tags, so no binding involved
<rick42>
(let A 1 ...lots.and.lots.of.lines,,, (let B 2 ...))
<beneroth>
Regenaxer, also no interning (in the global/higher scope) I assume?
<rick42>
beneroth: T
<Regenaxer>
beneroth, right
<Regenaxer>
interning is done by the reader typically
<beneroth>
rick42, yeah, I still like to keep variables near to their usage. got trained to that with C++ - in C which only allows variable declarations at beginning of a scope I found its becomes to much lookup-scrolling
<Regenaxer>
Like in rick42's example, lots of lines, then I separate the let's too
<beneroth>
Regenaxer, got that. I just assume that symbol tags (as in 'state) are not even internet in the global (all) tree - as I understand it, it would not make sense
<Regenaxer>
A matter of style, not relevant for performance
<beneroth>
ok. so you also say (let) is (must be anyway) cheap :)
<Regenaxer>
yes
<Regenaxer>
For 'state' you may use also transients
<beneroth>
also because in pil not much initialization is going on.. just reserving a cell, storing the name (and encode the type into the pointer)
<beneroth>
not big memory chunks reserved before actual usage
<Regenaxer>
T
<beneroth>
in C# (and C++) I got the habit of using more local scoping to prevent the building of big class instances when they might not be actually used
<beneroth>
just out of principle and style habits though - maybe premature optimization
orivej has joined #picolisp
<beneroth>
Regenaxer, I like (state) very much. needs some initial grokking but FSM is often a very nice and simple (and well maintainable) solution, I find
<Regenaxer>
yes, for some things very useful
<Regenaxer>
Recently I used it in @lib/vip.l
<Regenaxer>
for the markup
<beneroth>
and (state) is probably one of the simplest syntaxes to create an FSM in programming languages in general
<beneroth>
I use it for parsing input mostly
<beneroth>
to cleanly validate stuff
<Regenaxer>
yes, typical
<beneroth>
I feel tempted to create a graphical editor to create/edit (state) expressions :)
<beneroth>
(low priority)
<Regenaxer>
flowcharts?
<beneroth>
kinda, yes
<beneroth>
T
<Regenaxer>
Perhaps with graphviz
<beneroth>
aye. and maybe some SVG scripting to make it editable even
<beneroth>
I use graphviz to automatically generate ERDs
<Regenaxer>
I used it too recently, to generate a graph from DB objects
<Regenaxer>
very simple :)
<beneroth>
T
<beneroth>
I let run 'unflatten' over the do script I produced with picolisp before feeding it into 'dot' to produce a svg
<Regenaxer>
I used 'twopi'
<beneroth>
ah! nice
<Regenaxer>
needed a central blob with connected objects
<beneroth>
yeah perfect for that
<Regenaxer>
+Joint
<Regenaxer>
yep
<beneroth>
my ERDs tend to be multiple (often interconnected) trees
<Regenaxer>
ok
<beneroth>
(you remember my tricky inheritance structures ^^)
<Regenaxer>
yep
<beneroth>
unflatten makes the graphic more condensed
<beneroth>
I think I tried twopi too, but for that use case the results often just got weird
<beneroth>
so much cool FOSS tooling available
<beneroth>
so much stuff to build :D
<Regenaxer>
usefull stuff indeed
<beneroth>
Regenaxer, best way to seek to end of line? (from "^J") is probably cheaper than (line) or (line T) ... (eol T) does not exist :P
<beneroth>
is (line T) cheaper than (line) ?
<Regenaxer>
about the same
<Regenaxer>
both build up something
<Regenaxer>
so 'from' is better
<beneroth>
I assumed building a string (symbol name) would be slightly cheaper than building a list
<beneroth>
ok
<beneroth>
thanks :)
<Regenaxer>
(line T) builds less cells, but does a complicated bit-shifting