ygrek has quit [Remote host closed the connection]
ygrek has joined #picolisp
_whitelogger has joined #picolisp
_whitelogger has joined #picolisp
geri has joined #picolisp
<geri>
hey-hey, 久しぶりです
<abu[7]>
Hi geri, 本当
<geri>
:D
<geri>
how's it going?
<abu[7]>
all good
<abu[7]>
and you?
<geri>
found a lisp job, starting next month
<geri>
so very good as well
<abu[7]>
Great, congratulation!
<abu[7]>
Not PicoLisp I presume ;)
<geri>
thank you, thank you
<geri>
yeah, its clojure
<abu[7]>
oh
<abu[7]>
so not really Lisp
<geri>
lisp enough in my eyes to be happy about the position
<abu[7]>
true
<geri>
what do you typically do when you need a "structure"?
<geri>
like struct point { int x; int y; }
<abu[7]>
A class
<geri>
oh wait xd
<abu[7]>
ie a sym with properties
<geri>
yeah right, i forgot they existed
<geri>
thought you'd say pair encoding
<abu[7]>
also a way sometimes
<abu[7]>
properties *are* pairs anyway
<geri>
everything is!
<abu[7]>
T
<geri>
:D
<abu[7]>
except numbers to be exact
<geri>
yeah
<geri>
when using classes, can you differenciate object types?
<geri>
like (point? p)
<abu[7]>
Yes, with 'isa'
<geri>
ohh thats great
<geri>
i wrote a little thingie that lets you encode structures in lists and print them with custom syntax, but there's kind of little point to if you got oop
<geri>
remind me, was there any mechanism for multimethods in pil?
<abu[7]>
No, because this is a compiler issue
<geri>
not necessarily, but it can be pretty slow at runtime
<abu[7]>
In pil you dispatch on the args expuicitly
<abu[7]>
yeah
<abu[7]>
needs to interprete the args
<abu[7]>
It is only syntactical sugar
<geri>
dispatch on args explicitly like write a function that does what you need with cond? :D
<abu[7]>
right
<abu[7]>
Most pil functions do that
<abu[7]>
an arg check is needed anyway
<abu[7]>
for errors etc
<geri>
clojure's multimethods are very cool and somewhat simple
<geri>
you have a dispatch function that all arguments get fed into, resulting in some unique identifier, then you have a mapping between those identifiers and methods to call
<abu[7]>
ok
<geri>
gives you open extension, multiple dispatch, value dispatch, etc.
<geri>
but honestly like 90% of polynorphism is single-arg anyway
<abu[7]>
In Pil polymorphism is only on the type, not the following args
<geri>
yeah, understandable
<abu[7]>
no big thing, just different programming styles
<geri>
yee
<geri>
multiple dispatch is more powerful, but typically quite a bit slower and more complex
<abu[7]>
yes. If the types are known at compile time, different funs are compiled
<abu[7]>
otherwise it gets slow
<geri>
very
<abu[7]>
Lisp uses dynamic types, so often the type is not known
<abu[7]>
(de f (X) (g X)) (de g (Y) (if (num? Y) ..
<geri>
or you manually annotate everything, which isnt fun either
<abu[7]>
annotate in which way?
<geri>
like declare argument/return types
<geri>
common lisp lets you do that
<abu[7]>
T
<abu[7]>
getting static
<geri>
i honestly really like gradual typing
<geri>
sounds like best of both worlds
<abu[7]>
gradual?
<geri>
you can have purely dynamic typing
<geri>
you can also declare particular argument types, not having to declare everything
<geri>
or just declare everything if you want
<abu[7]>
right, but only for compiled code
<geri>
static typing makes no sense in an interpreter though imo
<geri>
ye
<abu[7]>
de
<abu[7]>
:)
<geri>
also ive been thinking, is there any tutorial on writing C extensions for pil?
<abu[7]>
There is one for 'native' iirc
<abu[7]>
not directly extensions
<abu[7]>
extensions would be PilSrc, not C
<geri>
well, just C functions that operate on picolisp data
<geri>
is there a tutorial for pilsrc? :D
<abu[7]>
This is supported by 'native'
<abu[7]>
(Lisp data I mean)
<geri>
just include pico.h i guess?
<abu[7]>
I mean the 'T' type
<abu[7]>
T # Direct Lisp value
<abu[7]>
in (doc 'native)
<geri>
i mean, calling C in picolisp is understandable enough, question is about calling picolisp from C :D