<beneroth>
abu[m], ok. I think I never used it. :D
<beneroth>
seems very handy
avocadoist has joined #picolisp
<beneroth>
cpli, well wanting to standardize that over multiple languages seems to be a stupid idea
<beneroth>
but so I understand correctly, you are asking for a way to define named parameters?
<beneroth>
" makes a procedure that can take keyword arguments in addition to positional arguments." that you get with a picolisp function (de fun(FirstArg SecondndArg . @) ....)
<beneroth>
FirstArg and SecondArg would be Formals in the wording of the article from your link, and @ would capture the rest of the argument list, which can be named parameters (or however the function likes to interpret them)
<abu[m]>
In any case, PicoLisp has no built-in syntax for named parameters
<beneroth>
up to the programmer
<abu[m]>
For an interpreter, it is an unacceptable overhead
<abu[m]>
The args need to be interpreted at runtime, just for a very little gain
<beneroth>
I would think it's aslo an unnecessary restriction. In picolisp you can decide how to handle an argument also depending on the argument type, or each argument can change the interpretation of the following arguments (like in named parameters, but not only)
<abu[m]>
T
<beneroth>
interpreted basing on type I found useful in DSLs, e.g. HTML DSL
<beneroth>
or you can do class inheritance structures with methods, which only handle some of the arguments of the method call, passing the remaining arguments to parent/alternative parent lineage method implementation to handle them
<beneroth>
this is used in the picolisp database schema implementation
<abu[m]>
Or you use free variable bound in the runtime environment
<abu[m]>
s/variable/variables
<abu[m]>
cause of shallow dynamic binding
<abu[m]>
*because
<beneroth>
abu[m], 'cause' is acceptable slang :D
<abu[m]>
yes, but could be misinterpreted in the above sentence
<beneroth>
aaah T! you are right
<abu[m]>
"cause" meaning "reason"
<beneroth>
good point
<beneroth>
well I fear we already overrun cpli :/
<abu[m]>
I'm not well concentrated atm (sitting in the dentist's waiting room ☺)
<abu[m]>
yeah, overrun, but IRC is persistent so no problem
<beneroth>
oh good luck. For a good outcome, or a short procedure
<abu[m]>
Thanks! But it is my wife being treated :D
<beneroth>
I had a check up just last week
<abu[m]>
perfect
<beneroth>
ah alright. nice you accompany her
<abu[m]>
I'm just the driver
<abu[m]>
She may be dizzy after the operation, so she should better not drive
<cpli>
beneroth> well wanting to standardize that over multiple languages.. stupid
<beneroth>
yeah that's sensible
<cpli>
they're all implementing scheme
<beneroth>
cpli, yeah then it might work. but looks like that was already a hazzle
<beneroth>
I would think either the differences are too big to do really a meaningful standardization, or the differences are to small to keep those languages as separat languages
<cpli>
i.e. this is a proper issue, and none of them can agree on any way to handle - much less define - named arguments
<beneroth>
so whats the difference in scheme implementation, so they're dialects? it's not just multiple technical independent implementation of the same language.
<cpli>
they're all the same dialect of lisp
<beneroth>
(not like e.g. different C compilers. which also have their specific stuff, unfortunately, but largely handle the exact same language)
<abu[m]>
For a compiled lang named params might make sense. I personally find it a bit too verbose
<beneroth>
they can be useful for huge functions
<cpli>
beneroth, __attribute__((<values)) are named different between clang and gcc
<abu[m]>
T
<beneroth>
then again, maybe such huge functions should not exist and be a DSL in their own
<beneroth>
cpli, yeah we are not overly fond of clang.
<cpli>
we are not?
<beneroth>
they have a very closed attitude to e.g. dynamic arrays
<beneroth>
in picolisp C implementation dynamic arrays were used for memory management
<cpli>
how so?
<cpli>
hmm
<cpli>
dynamic arrays?
<beneroth>
clang devs find them abhorrent (which might correct in the standard C/C++ use cases but not so true for implementing your own language virtual machine)
<abu[m]>
variably sized arrays
<beneroth>
and they put a message in clang that they also never will consider them and everyone who uses them is horrible, kinda :D
<abu[m]>
iirc
<beneroth>
ah right
<cpli>
are they part of C?
<cpli>
or were they some clang extension
<beneroth>
gcc extension
<beneroth>
never in clang
<abu[m]>
Not sure. I liked them. You need to use alloca() instead
<beneroth>
I think they were on track to get into C standard but never ended up there officially
<cpli>
does alloca give page/alignment guarantees?
<abu[m]>
yes
<cpli>
hmm
<abu[m]>
I use the analog of it in @src/lib/llvm.l
<abu[m]>
But due to clang's restriction I never ported pil32 to clang
<abu[m]>
Some other people did as far as I know. Don't know if it is used
<beneroth>
I don't know neither
<abu[m]>
So I never looked at clang, and went straight to LLVM-IR
<cpli>
i hope you don't mind me asking, I'm 20 years old, as the head dev behind picolisp, what's your age?
<abu[m]>
Gives more control anyway
<beneroth>
btw. abu[m] I found the article from Microsoft about why they hate fork()
<beneroth>
but it's all about threading.
<abu[m]>
I'm 69 now
<abu[m]>
oh, hate fork()? Don't they have other problems?
<beneroth>
well they don't have fork() in windows for principled reasons
<abu[m]>
I think fork() is a strike of genius
<abu[m]>
Windows has clone()
<beneroth>
it's not that they (MS) never cared to not put it in windows, they thought about it and disliked it
<abu[m]>
i.e. fork() + exec()
<beneroth>
how does clone work ?
<abu[m]>
I never looked deeper
<beneroth>
hm...but would that not fulfill everything needed for pil vm?
<beneroth>
I mean pil vm always does fork() + exec() practically, no?
<cpli>
the fact that fork so unabashedly reveals its internals, i.e. the same stack written to another process just for you to have to figure out how to handle it is kind of peculiar
<abu[m]>
fork is more powerful, because you can control the new process before exec()
<beneroth>
ok
<beneroth>
cpli, well for a process (vs. a thread) it is a different stack, just a copy, practically, no?
<abu[m]>
cpli, I think the writing does not happen
<abu[m]>
write on demand
<abu[m]>
so fork is very efficient
<abu[m]>
yeah, threads are also just forks
<cpli>
beneroth, that might be true but these people are probably asking to seperate threadpools from getting shot down by the kernel, no?
<beneroth>
cpli, well don't use threads and then the whole argument fails, no?
<cpli>
pardon?
<beneroth>
" A program could
<beneroth>
initialise, parse its configuration files, and then fork multiple
<beneroth>
copies of itself that ran either different functions from the
<beneroth>
on in pre-forking servers"
<beneroth>
same binary or processed different inputs. This design lives
<beneroth>
(from the MS PDF)
<beneroth>
that is practically how pil uses it, as I understand it
<cpli>
pthreads are - i assume - just forks too
<cpli>
nope
<cpli>
i'm in the wrong.
<beneroth>
threads live in the same stack. that is both the big advantage of threads and also kinda why people either use it very carefully (and still blow up sometimes) or put in so many guard rails that it becomes inefficient again
<beneroth>
the functional programming crowd, especially since clojure, hail immutability (never edit memory/variables/data, always make copies) as a solution to this
<beneroth>
ironically most functional programming language implementations are very bad at concurrency
<beneroth>
so picolisp is also a Lisp-1 like Scheme
* beneroth
wonders how code is data can truly work when you separate functions from data
<abu[m]>
beneroth: Threads do *not* live in the same stack. Each thread needs its private stack. The *heap* is shared between threads
<abu[m]>
Same as coroutines in Pil in that regard
<abu[m]>
Separating functions from values refers only to the pointers in symbols
<abu[m]>
When symbols have separate slots fof value and function definition
<abu[m]>
(in pil it is always a single 'val')
<beneroth>
abu[m], right, that makes more sense. Thanks xD
<beneroth>
separating: yeah same could be done in pil with namespacing, in a sense
<beneroth>
you're right. I used to know that.
<abu[m]>
Namespaces won't help. The point is you can do (setq car 123) and (car Lst) still works
<abu[m]>
Or (let car XXX ... (car ...) ...
<abu[m]>
I think it is a waste of space
<abu[m]>
Symbol size doubles
<abu[m]>
And Pil is case sensitive, so you do (let Car XXX ... (car Lst)
<beneroth>
might be useful for compiling
<abu[m]>
One huge flaw of CL and Scheme is that they are not case-sensitive
<beneroth>
they're not? wow!
<abu[m]>
A relict of ancient computer times
<beneroth>
that I definitely didn't know
<abu[m]>
yeah
<beneroth>
ok
<abu[m]>
Car and car are all CAR internally
<beneroth>
well I actually do sometimes local shadowing of functions using (let). I find it very useful.
<abu[m]>
indeed
<beneroth>
the most extensive use I made was for a parser which can parse from stream and from a string. the parsing is the same function, I think the string parser just rebinds some of the reading functions
<abu[m]>
Same with 'gui' in @lib/form.l
<beneroth>
and in very nested code I sometimes rebind (quit) similar to how redef works, to decorate the error message without having to have very long error messages in the calls
<beneroth>
abu[m], T
chexum has quit [Remote host closed the connection]
chexum has joined #picolisp
avocadoist has quit [Quit: Konversation terminated!]
avocadoist has joined #picolisp
seninha has joined #picolisp
seninha has quit [Ping timeout: 265 seconds]
seninha has joined #picolisp
rob_w has quit [Remote host closed the connection]