theruran has joined #picolisp
emilesnyder has joined #picolisp
<
geri>
abu[7]: it was to show you can do multiple expressions in exe
geri has quit [Remote host closed the connection]
emilesnyder has quit [Quit: Leaving.]
galambo has joined #picolisp
galambo has quit [Quit: Leaving]
<
tankf33der>
i've setuped a full monero node. pure fun. lets see how long.
<
abu[7]>
Merry X-Mas everybody!
geri has joined #picolisp
<
geri>
im still thinking what to do about symbol collisions in my lisp
<
geri>
just got an idea to do a fun overload
<
geri>
in pil, pico~sym will return "sym" in namespace pico, im gonna use . for it
<
geri>
but if . is the first character, then it just interns the symbol in private namespace
<
geri>
so everything read afterwards is nice and secure
<
geri>
how bad does it sound?
<
abu[7]>
Hmm, why not use (private) ?
<
geri>
i dont have (private)
<
geri>
because its verbose and ugly, but really it does the same thing
<
abu[7]>
ok, but transients?
<
geri>
like using gensyms?
<
geri>
i dont have transients in picolisp's sense either
<
abu[7]>
Why ugly? Privates are very clean
<
geri>
(private) thing vs .thing
<
geri>
with . always being same as introducing a new private
<
abu[7]>
using a "." name prefix?
<
geri>
but its not really a prefix
<
abu[7]>
But then these syms may collide
<
abu[7]>
a read macro?
<
geri>
its supposed to be a read macro to force "thing" to be re-interned in private namespace
<
geri>
only problem im thinking is
<
geri>
same in picolisp probably
<
geri>
what if i do (private) car
<
geri>
do i need to zap it to get pico's car?
<
geri>
or always do pico~car
<
abu[7]>
Yes, no conflict with pico~car
<
abu[7]>
No need to zap
<
geri>
but if i want to have car in my current namespace without prefixing?
<
abu[7]>
(import pico~car)
<
geri>
so i guess in any case you'll have to undo (private) manually if you need to
<
geri>
oh also i wrote proper destructuring for my lisp
<
geri>
so now i can do (lambda ((a b . d) c) ...)
<
geri>
made eval 2 times smaller, im happy
<
abu[7]>
The inline eval?
<
geri>
no, but honestly i should do that when ill migrate to a proper language
<
geri>
instead of python
<
geri>
it's fun how compilers can make "functions are slow" into "small functions are faster"
<
geri>
also i found out today you can do pico~pico~pico~pico~car :D
<
geri>
also-also, does (match) just override latest bindings if the symbols matched instead of introducing new ones?
<
geri>
i think it uses set
<
abu[7]>
Yes, 'match' just 'set's
<
geri>
that sounds way less safe than what let does
<
abu[7]>
So I use 'use' before 'match'
<
abu[7]>
No safety problem
<
geri>
which is basically a worse let
<
geri>
maybe faster, dont know
<
abu[7]>
More gereral
<
abu[7]>
uses placeholders
<
abu[7]>
it is not a "bind"
<
geri>
Use also pushes stuff to the bind stack it seems
<
abu[7]>
'match'? No bind stack
<
abu[7]>
'let' is 'use' + 'setq'
<
abu[7]>
Originally pil only had 'use'
<
geri>
silly question - do you know how much overhead does supporting (let Sym Val ...) vs (let (Sym Val) ...) add?
<
geri>
i guess + convinience and a little less consing
<
abu[7]>
Very little
<
abu[7]>
More cells to 'gc'
<
abu[7]>
No consing at runtime
<
geri>
oh i meant like
<
geri>
the atom? call :D
<
geri>
atom without question mark*
<
geri>
i wonder what costs more
<
geri>
an extra cons cell or extra atom call
<
abu[7]>
Very very little. Unmeasurable
<
geri>
yeah probably that
<
abu[7]>
You could bench it
<
geri>
i mean, atom is gonna be in there anyway
<
geri>
couldve been always a list alternatively, but thats fun with recompiling to test
<
abu[7]>
afk a while
<
geri>
i may go to bed soon
<
abu[7]>
Sleep well!!