igemnace has quit [Remote host closed the connection]
asarch has quit [Quit: Leaving]
hashfunc17b4 has quit [Ping timeout: 240 seconds]
anticomputer has quit [Remote host closed the connection]
anticomputer has joined #commonlisp
Oladon has joined #commonlisp
karlosz has joined #commonlisp
zacque has joined #commonlisp
frgo has quit [Read error: Connection reset by peer]
<Josh_2>
GM :sunglasses:
nature has joined #commonlisp
ttree has quit [Ping timeout: 260 seconds]
karlosz has quit [Quit: karlosz]
taiju has quit [Ping timeout: 244 seconds]
xaltsc has joined #commonlisp
rotateq has joined #commonlisp
lisp123 has joined #commonlisp
karlosz has joined #commonlisp
gxt has quit [Ping timeout: 240 seconds]
lisp123 has quit [Ping timeout: 258 seconds]
gxt has joined #commonlisp
Dynom has joined #commonlisp
random-nick has joined #commonlisp
karlosz has quit [Ping timeout: 258 seconds]
<grawlinson>
so how does one bootstrap ccl?
<grawlinson>
assuming all ccl binaries somehow disappear from the internet
<jackdaniel>
then you can't
<jackdaniel>
fwiw the same applies to gcc
<jackdaniel>
or in a matter of fact to most compilers
machaddr has joined #commonlisp
<jackdaniel>
(i.e you need to compile them with something)
<rotateq>
Or like with GHC.
pve has joined #commonlisp
<jackdaniel>
of course it would be better if ccl could be bootstrapped from any conforming cl implementation (and not only its previous version)
<grawlinson>
sounds like a can of worms that's better closed
<rotateq>
jackdaniel: You mean like CLISP in earlier days was used to bootstrap SBCL on other platforms? Or did I misread that at another point?
<jackdaniel>
sbcl was forked from cmucl (among other reasons) to allow "sane bootstrap procedure" - i.e to be able to build sbcl from any conforming common lisp implementation
<jackdaniel>
if you can bootstrap the implementation from a conforming common lisp, then indirectly you may bootstrap it also from a conforming c compiler (vide clisp or ecl)
<rotateq>
Yes I know that. :)
<jackdaniel>
being tied to a previous version of the same implementation brings some nuisances even when binaries are available - for example when you port software to another platform
<jackdaniel>
then you need to cross-compile it, and that's usually hairy
<jackdaniel>
(ignoring the whole effort to build a compiler targetting the platform in question)
<jackdaniel>
s/ignoring/even when we ignore/
<random-nick>
you might be able to bootstrap sbcl from abcl too
<rotateq>
Still much dark magic for me.
<beach>
rme once told me that it would not be too much work to make it possible for CCL to bootstrap on any conforming Common Lisp implementation. But I guess nobody is really maintaining CCL anymore, perhaps?
Oladon has quit [Quit: Leaving.]
<Nilby>
So therefore any CL that can bootstrap from CLISP or ECL, should be also able to bootstrap from mes and the binary seed: https://www.gnu.org/software/mes/
<beach>
Maybe this is a good time to remind #commonlisp participants of my idea of a "bootstrap Common Lisp", or BOCL. The sole purpose would be for it to be used to bootstrap other Common Lisp implementations, so maintenance goes before performance.
dec0d3r has quit [Quit: Leaving]
<rotateq>
beach: I would have guessed this could be an additional goal for SICL too.
<grawlinson>
BOCL sounds like a good idea, if I'm being honest
<beach>
rotateq: SICL is very concerned about performance. It is meant to be used in production. If you look at the papers we published, most of them are about performance.
<beach>
grawlinson: The idea is to write it in very portable C.
dider has quit [Ping timeout: 255 seconds]
<grawlinson>
C89 then, I guess
<beach>
I take your word for it. I haven't followed the evolution of C.
<rotateq>
Not in ANSI or ISO C? I always confuse the versions.
<rotateq>
There's even this proven C compiler CompCert.
<random-nick>
rotateq: C89 is the ANSI C from 1989
<beach>
Some examples of non-optimizations would be to have all objects represented the same way, so as to avoid special treatment of fixnums and other "immediate" objects.
<beach>
Another would be to not bother with tail-call optimization.
<random-nick>
there was that one entirely C implementation jackdaniel sent a link to here some time ago, but it's probably not very conforming since it couldn't even load ansi-test
<rotateq>
random-nick: Ah okay thanks. You want something to rely on in serious production.
<rotateq>
Oh that one, I remember.
<beach>
random-nick: Even the current implementations entirely in C are usually meant for production use, so they include lots of optimizations that make maintenance more difficult.
<grawlinson>
I was wondering where I recognised SICL from, I compiled clasp a few days ago for the fun of it :p
<beach>
random-nick: On the other hand, BOCL doesn't need to be entirely in C, as long as Common Lisp code can be loaded into a "core" written in C.
<beach>
grawlinson: SICL and Clasp are very different systems, but they both use a version of the Cleavir compiler framework that originated from the SICL project.
analogsalad has joined #commonlisp
<beach>
grawlinson: Clasp is written in C++, whereas SICL is written entirely in Common Lisp.
<rotateq>
From what little I read in #clasp they often fight C++ things to fit in. (just an observation)
<beach>
Yes, C++ is not a great language, but one of the goals was to interoperate with existing C++ libraries, so I guess they felt they had no choice.
<beach>
Oh, and they use LLVM for code generation, and it's main API is C++.
<random-nick>
beach: but I don't really see the need for a BOCL, the current releases of clisp and abcl are going to stay compatible with their current platforms for a long time, even if development stopped now
<rotateq>
So I have even more respect for what is being done and what has already been done, not to mention the chemical side with cando.
<beach>
random-nick: I am betting they are not entirely conforming, so if they are not maintained, it would be hard to improve them.
<beach>
random-nick: Existing implementations are fairly complicated and specific to the goals of the creators. But BOCL would not have any such specific goals, so it should be more easily maintained.
<beach>
random-nick: But don't worry about it. I have noted your opinion, and I am not trying any further to convince you otherwise.
<rotateq>
We need a proof system that checks if an implementation is entirely conforming. :)
notzmv has quit [Ping timeout: 255 seconds]
Josh_2 has quit [Quit: ERC (IRC client for Emacs 27.1)]
<beach>
Besides, it's an amusing mental exercise to deliberately avoid thinking of performance optimizations.
<flip214>
that's like horse betting based on a theory "Let's assume the horses are massless points..." .... ;)
attila_lendvai has joined #commonlisp
<grawlinson>
question, how does one ensure "/" is postfixed to the end of a pathname returned by merge-pathnames?
kpoeck has joined #commonlisp
<jackdaniel>
if you merge only directories, then the namestring of a resulting pathname will probably have "/" at the end
<jackdaniel>
I don't think that bocl would meet the conformity level of (say) clisp for a simple fact that it would not be very much used. many bugs are discovered by extensive use
Cymew has joined #commonlisp
zacque has quit [Quit: Goodbye :D]
pjb has joined #commonlisp
<Nilby>
there is no such thing as portable C code, only ported C code
<jackdaniel>
:)
<rotateq>
That's sad as so much of civilization builds on it.
lisp123 has joined #commonlisp
<beach>
Well, by "highly portable", I really meant "using only constructs with defined semantics"
<beach>
But yeah, apparently most C programs violate the standard. Especially operating systems and (I guess also) language run-times.
gxt has quit [Ping timeout: 240 seconds]
shka has joined #commonlisp
infra_red[m] has quit [Quit: You have been kicked for being idle]
gxt has joined #commonlisp
trocado has quit [Ping timeout: 240 seconds]
lisp123 has quit [Remote host closed the connection]
analogsalad has quit [Quit: bye]
Brucio-61 has quit [Ping timeout: 260 seconds]
scymtym has quit [Ping timeout: 260 seconds]
lisp123 has joined #commonlisp
orestarod has joined #commonlisp
<lisp123>
It would be good if there were some CL implementations were written in terms of a minimum subset of CL (something lightweight like Scheme)
<lisp123>
Then it can be embedded more easily in other languages
<beach>
Why would you want to embed a Common Lisp implementation in another language?
<lisp123>
So I can use it in closed system
<lisp123>
Not that it matters, I'm happy to reimplement a small subset for my own purposes in JS
<beach>
What do you mean by "closed"? As in "not open source"? If so, how would you embed the Common Lisp implementation?
<lisp123>
Nah, like a browser
<lisp123>
or like a running Python image (? if thats the right word) like we have at work
<lisp123>
Or within Swift for iOS Apps
<beach>
You mean you take some existing code that you are allowed to modify, and you incorporate a Common Lisp implementation into that code?
<beach>
But that code is written in something else like C++ or C?
<lisp123>
Sort of yes
<lisp123>
Indirectly they are
machaddr_ has joined #commonlisp
<lisp123>
That's where scheme gets used a lot no?
<lisp123>
Being embedded
<beach>
I don't know. I would think it would be hard to embed a Common Lisp system into some existing software that was not designed to do that already. No?
<lisp123>
I imagine it would be
<lisp123>
But for example, ECL is written in C
<beach>
Yes, and?
<lisp123>
if there was a version were only X subset of CL that needed tobe written in C, and the rest could be bootstrapepd from X
machaddr has quit [Ping timeout: 272 seconds]
<beach>
I think that's the case for most Common Lisp implementations written in C.
<lisp123>
then it would be easier for someone else to try to port that to Rust or Swift
<beach>
... or any other language for that matter.
<lisp123>
I see
<beach>
It is just too hard to write something like a conforming Common Lisp compiler in something other than Common Lisp.
<lisp123>
Its a big city language for sure
<beach>
But that wasn't my question. My question was how you were planning to use this embeddable Common Lisp implementation.
scymtym has joined #commonlisp
Brucio-61 has joined #commonlisp
<lisp123>
I am planning on using a subset of CL in the browser
<lisp123>
for users to write small CL code
<lisp123>
But I do it client side because I don't want to pay for their server costs
<beach>
Ah, so it would not interact with the browser logic? Just be a Common Lisp implementation?
<beach>
I'm lost.
machaddr_ is now known as machaddr
<beach>
"server cost"?
<jackdaniel>
ECL may be embedded in a program written in C
<jackdaniel>
most notably because it is a shared library that may be simply linked
<lisp123>
Well I could just receive their messages and process it on the server in a real CL image
<jackdaniel>
then you may call cl_eval(…), or even cl_compile(…) from C code
<jackdaniel>
also, lately, sbcl also gained this capability
<lisp123>
beach: I am embedding a subset of CL in JS
<beach>
lisp123: OK, now I am really lost. What messages are we talking about in a browser, and why would you receive messages from a browser user?
<beach>
lisp123: I just don't understand what you mean by "embedding". If it does not interact with the browser logic, then it is equivalent to an autonomous Common Lisp implementation, no? So why have it in a browser?
<lisp123>
Why have it in a browser --> No need for installation
<beach>
Hmm.
<jackdaniel>
if the common lisp implementation is implemented in js (or, for example, targets WASM), then the user may open a website and run a conforming common lisp implementation using that browser as a host platform
<lisp123>
Browsers are just the most common Virtual Machine out there
<jackdaniel>
it will implode like a black hole (from too many implementations)
<lisp123>
The implementations are slowly consolidating into a few though
<jackdaniel>
are they though?
<lisp123>
SBCL seems to be de facto
<beach>
lisp123: You just said you are working on another one.
<beach>
<rotateq>
Just in terms of user numbers maybe.
<lisp123>
One thing I don't like is that many programs dont run on anything but SBCL
<lisp123>
You would hope people would take ANSI compliance more seriously
<jackdaniel>
quicklisp has a requirement that a program needs to run at least on two implementations
<lisp123>
Maybe I just had issues with Ironclad and BKNR
<rotateq>
lisp123: Yes, not just the beginning learning process should focus on that.
<jackdaniel>
my impression is that more cl libraries are making an effort to be portable
<jackdaniel>
(than libraries that are not making such effort)
<lisp123>
beach: quality of anything i do cant be included in such numbers ;) plus its only a subset
<lisp123>
jackdaniel: I wonder if somebody would be keen to do a test of popular libraries and do a report
<jackdaniel>
mcclim (and it has plenty of dependencies) runs fine on sbcl, ccl and ecl -- and it is reported to run on other implementations too (I'm regularily using these three)
<jackdaniel>
so that's for a sanity check; similar applies to a few other libraries I use
<lisp123>
Fails on LispWorks but I think we discussed that in the past
<jackdaniel>
this could be, I'm not testing things on LW
<lisp123>
jackdaniel: how much work to get CL working on WASM?
notzmv has joined #commonlisp
<jackdaniel>
I was able to get to the repl with ecl on wasm with a few terrible hacks a few days back
<jackdaniel>
when the thing is appropriately cleaned up I will make a proper merge request with support
<lisp123>
awesome
<jackdaniel>
that said, it did work only with the bytecodes compiler
<lisp123>
no big deal
<jackdaniel>
it kind of is, but OK ;p
<lisp123>
performance isn't the greatest concern for the browser imo :)
<lisp123>
we should link up in the future, i'm writing an editor for the browser, we could combine this with ecl to give a full experience to users
<jackdaniel>
if you want to run mcclim on ecl+sdl2 in a browser, it kind of is
<lisp123>
what is sdl2?
<jackdaniel>
a library written in C
<lisp123>
i see
<jackdaniel>
that works with emscripten
<jackdaniel>
(because, to make things clear, I've used emscripten, I did not write a backend targetting wasm vm)
<rotateq>
lisp123: Or you get employed at LW and fix it for them, so McCLIM runs. :)
<lisp123>
rotateq: you are closer to London now ;)
<jackdaniel>
I think that fixing it does not require getting access to lw internals, just a person who uses both lw and mcclim and wants it to run
<lisp123>
Or Cambridge, to be more precise
<rotateq>
lisp123: Me? Best joke of the year possibly. :) [not the location attribute]
razetime has joined #commonlisp
<lisp123>
I'm sure they would love to have you on board
<rotateq>
That's kind, but I want to stay realistic. ^^
treflip has joined #commonlisp
triffid has quit [Ping timeout: 240 seconds]
triffid has joined #commonlisp
lisp123 has quit [Quit: Leaving...]
treflip has quit [Read error: Connection reset by peer]
treflip has joined #commonlisp
treflip has quit [Client Quit]
seok has joined #commonlisp
<seok>
is CL-prevalence the best option for in-memory persistent object store?
<seok>
clobber looks slightly newer but prevalence looks bigger
<contrapunctus>
seok: see Clobber's README
<seok>
ok
tyson2 has joined #commonlisp
treflip has joined #commonlisp
lisp123 has joined #commonlisp
<lisp123>
how does clobber compare to BKNR?
weary has joined #commonlisp
<rotateq>
Ah that's what clobber is for. I reread chapter 21 of of CL Recipes book by Edi and got in touch with bknr.
<lisp123>
one day i hope to learn how to implement BKNR or clobber, it is a good exercise for MOP learning
<weary>
jackdaniel: you got ECL working on wasm? congratulations! i had a miserable time dealing with emscripten. have you enjoyed your time with it?
machaddr_ has joined #commonlisp
machaddr has quit [Ping timeout: 246 seconds]
prokhor_ has joined #commonlisp
lisp123 has quit [Quit: Leaving...]
Oddity has quit [Ping timeout: 240 seconds]
paule32_ has joined #commonlisp
paule32_ has quit [Changing host]
paule32_ has joined #commonlisp
<weary>
on that note, does anyone else know of any other CL-over-wasm attempts that were at least partially successful? aside from my attempt (terrible unpolished hack, but working, which is cool) and apparently now ECL, i haven't seen any, but i would love to see that others beat me to it (hopefully with a less hacky approach than mine).
paule32__ has joined #commonlisp
paule32__ has quit [Changing host]
paule32__ has joined #commonlisp
paule32 has quit [Ping timeout: 260 seconds]
paule32_ has quit [Ping timeout: 246 seconds]
paule32__ has quit [Read error: Connection reset by peer]
paule32__ has joined #commonlisp
paule32__ has joined #commonlisp
paule32__ has quit [Changing host]
machaddr_ has quit [Quit: Leaving]
anticomputer has quit [Remote host closed the connection]
anticomputer has joined #commonlisp
alvaro121 has joined #commonlisp
attila_lendvai has quit [Ping timeout: 244 seconds]
waleee has joined #commonlisp
anticomputer has quit [Remote host closed the connection]
anticomputer has joined #commonlisp
aartaka has quit [Ping timeout: 255 seconds]
aartaka has joined #commonlisp
MajorBiscuit has joined #commonlisp
<dbotton>
that is awesome news :) (ECL on wasm) CLOG works on ECL (win,mac,iOS,Android) and the same basic hack use for iOS and Android should work to get it running on browser. jackdaniel I can't wait to get a chance to play with it :)
<dbotton>
My plan is to allow someone developing with the builder to be able to with a check mark decide if to run the lisp on server or client at any time.
Bike has joined #commonlisp
<weary>
emscripten's really interesting because it's both surprisingly capable and also completely incompetent at doing whatever you want it to do at any given time.
<weary>
you want surprisingly-robust sockets? you've got them! you want basic io that isn't terrible? no.
azimut_ has quit [Remote host closed the connection]
<weary>
it's probably worth not getting your hopes up for anything too useful, but it's still pretty cool that there are web cls now; i certainly learned a lot getting mine to work, although not sure how useful any of the knowledge i gained will ever turn out to be.
azimut has joined #commonlisp
<weary>
that does make me curious about getting sdl to work with mine though; if i ever revisit it i will have to give it a look
<dbotton>
CLOG is 100% CL from start, the only part that uses any thing outside the standard is something easily switched out, the websocket. So as long as I can execute a line of JS good to go
<dbotton>
can you switch out to use html canvas instead of sdl?
taiju` has joined #commonlisp
Th30n has joined #commonlisp
razetime has quit [Ping timeout: 255 seconds]
<weary>
emscripten allows you to call js from c (i had to call a lot of js from c to get mine working). if your implementation of cl on the web supports poking holes via ffi of some sort or another, you could actually just write a quick wrapper to call the js you want adirectly.
<weary>
that said i have absolutely no idea how the canvas api works, so that would be something for another lisper to try whenever ecl patches get released by jack.
<jackdaniel>
weary: I certainly did not enjoy the experience ,)
<weary>
also, when jack mentioned sdl, he meant emscripten's built-in sdl support: it lets you make graphical software like you would in c, but on the web. you wouldn't need something like that for canvas.
<jackdaniel>
dbotton: there is no news, cleaning up will take time, and that comes after fast generic function dispatch (that, on the other hand, is nearly finished)
<weary>
jackdaniel: i had to do probably less than 1/100th the work you did to get mine working, and it was *awful.* totally get it.
<dbotton>
Is ok, I still have more to do where I am right now, all will come together in their time
<jackdaniel>
weary: the biggest hurdle was with making contribs work
<jackdaniel>
(I mean - essential contribs, like libgc and gmp)
morganw has joined #commonlisp
MajorBiscuit has quit [Quit: WeeChat 3.4]
treflip has quit [Remote host closed the connection]
<rotateq>
How is the technique for fast generic dispatch? I can imagine something like "so for this context it's sure incoming data has this and this signature, so we can immediately call the method that fits and don't enter the pipeline for dispatching for every new amount of the same kind of data".
Guest74 has joined #commonlisp
<jackdaniel>
you may check out beach paper that describes it
<beach>
The technique I invented is nothing as sophisticated as that. It just recognizes that table lookups imply memory access, which means it is slow.
<weary>
jackdaniel: oh, did you get boehms to work with pthreads turned on? i just turned them off when i was still trying to get other cl implementations to work. i actually got pretty far in the process before it would explode and then i decided to take an easier (fewer/zero deps) implementation and get it to work instead.
<rotateq>
Okay.
<jackdaniel>
classes are represented as numbers, and you take each instance class's number and do a binary search
<jackdaniel>
this technique works well when all is already known and compiled, but it has a big downside that for "unknown" calls it must recompile a function, so it is very slow at the beginning (multiple recompilations)
<jackdaniel>
weary: no; the hack doesn't have threads. I've said that it is not even close to complete, just I've been able to run it
<rotateq>
jackdaniel: "classes are represented as numbers" sounds a bit as a Gödelisation :)
<beach>
It is just a unique number stored in a slot of the class.
<jackdaniel>
well, the class has a stamp (an index), and instance has a stamp (an index) - so testing whether the instance needs updating is just a number comparison
<beach>
Minor correction: Only the instance has a "stamp", which is the unique number of the class as it was when the instance was created. The class contains a "unique number".
<jackdaniel>
I see
<beach>
But your description is very good. I couldn't have said it better myself. :)
<beach>
rotateq: Also important is that the comparisons in the binary search are between 1. A register containing the stamp of an instance and 2. Small constants (the unique class numbers) that are generated as part of the compilation process that generates the discriminating function.
<beach>
So the comparisons are very fast.
<beach>
And they do not access memory.
<rotateq>
Ah I see, as register access is the fastest and an integer always fits.
<jackdaniel>
there are still memory accesses but there are fewer
<beach>
Yes, unless you redefine a class every clock cycle, and run your computer for a few months.
<beach>
There is a memory access to get the stamp from the instance, but there are no memory accesses in the binary search.
<jackdaniel>
you need to take a stamp from each instance, and then there are eql comparisons in case of eql specializers
<beach>
Sure.
<rotateq>
And then get the entry address where the certain method begins to call on the arguments?
<beach>
rotateq: That's no different from existing techniques.
<rotateq>
Okay.
<jackdaniel>
effective method functions may be additionally compared, so if they are the same, then you may merge some tree paths (further optimizing the binary search)
<jackdaniel>
also, for arguments that have no specialization whatsoever you don't need to access the instance stamp
<beach>
rotateq: All my technique does is replace table lookups (a version of hashing in PCL) by this binary search.
<jackdaniel>
either way; another in the pipeline for ecl performance improvements is a type inferencer (that is based on nimble type inferencer with a few adjustments to make it conforming for common lisp)
<jackdaniel>
the idea is only on paper, but that's what I'm going to jump at after merging fast gf
<rotateq>
And the unique class number is given by a hash function?
<rotateq>
I'll try reading the paper.
<beach>
rotateq: No, start with 0 and increment each time a class is redefined.
<rotateq>
Well, I know that if I ask something like that here, there will be an accurate answer, whether I understand it or not. :)
<rotateq>
Okay, that's another option, right, just guessing.
<beach>
The numbers do not require the characteristics of hash codes, because they are not used for hashing.
<beach>
But it is good if they are small, because then they will fit in a field in the instruction.
<rotateq>
I guessed this due to the requirement of uniqueness.
<rotateq>
Ah makes sense, to store more information in one register entry.
<beach>
No, in the instruction field.
<rotateq>
Oh okay.
<beach>
The instruction will compare a register (containing the stamp) to a small-ish constant. So the constant will be encoded in a field of the instruction.
ecraven has quit [Ping timeout: 248 seconds]
ecraven- has joined #commonlisp
<beach>
Each test in the binary search will use the same stamp/register, but a different constant.
<beach>
E.g., "is the register less than 243?" then if it is "is the register less than 101?", etc.
<beach>
The number of comparisons increases by the number of methods, but only by lb(n).
<jackdaniel>
well, that's up to the underlying compiler. i.e if you transpile to C, then you have "just" constant compared with the variable (with both having size uint64_t for that instance)
<rotateq>
Okay and with a binary search you reach the end fast, even if many methods are defined for a generic function.
<beach>
rotateq: Correct.
<beach>
rotateq: And nothing prevents the implementation from switching to a table-based lookup if the number of methods is truly huge.
<rotateq>
Many as in hundreds or so.
<beach>
Right. Then you start getting up to 7 or so comparisons.
causal has joined #commonlisp
<beach>
I do hope the paper is not too hard to read and digest.
<rotateq>
Do you mean because of me or at all?
<beach>
I meant, I hope it doesn't require too much detailed knowledge of architecture, compilation techniques, etc., etc.
<jackdaniel>
the gist idea is well laid out there, technical details like invalidating part of the history entries is more tricky (i.e when you can do what), but that's outside of the scope of the paper
<beach>
It was a while ago, so I don't remember.
<rotateq>
Yes I see. Maybe I can write down specific questions to certain text points.
<beach>
And jackdaniel is right. The binary search itself would not be publishable. The important part of the paper as far as the peer review process is concerned, is the interaction with actions such as redefining classes, adding/deleting methods, handling object types not yet seen.
Cymew has quit [Ping timeout: 255 seconds]
<beach>
A complementary technique (in a different paper) is "satiation", where the call history of a generic function can be pre-filled with all possible effective methods, so that the discriminating function does not have to be re-created as a result of "faults" for new arguments. This is important for system functions.
imjim has joined #commonlisp
<beach>
... and it's related to another paper entitled "replacing metastability issues with bootstrapping issues" or something like that.
<jackdaniel>
actually I'm not doing any satiation and the technique works just fine
<beach>
Great!
<beach>
You don't want to have a fault in the function CREATE-DISCRIMINATING-FUNCTION, because then its discriminating function must be re-created, and that could be problematic.
<rotateq>
I would have to learn more about those and how it's normally handled.
* beach
feels that the name of that function is wrong, maybe?
<jackdaniel>
compute-
<beach>
Ah, yes, thanks.
<jackdaniel>
sure
imjim has quit [Quit: thank you]
<rotateq>
And did you know? Multi dispatch is bad and can't work. (in C++)
<beach>
rotateq: If you want to know how it is "normally" handled, you need to read the AMOP book. But the way it is handled by PCL is to special-case many things. I didn't want that, so I invented satiation.
<beach>
rotateq: The problems with metastability are documented in the chapter entitled "Living with circularity".
<rotateq>
That's still on my list of course. :) Or reading more than the little I have read by now.
<beach>
But they can be forgiven because PCL was designed to be "bolted onto" a pre-ANSI Common Lisp implementation.
<jackdaniel>
rotateq: it is bad when you want to compile the discriminating function when the code is initially compiled (like with c++)
<beach>
SICL is bootstrapped from an existing full-ANSI Common Lisp implementation, so we can avoid some of the metastability problems.
<rotateq>
Ah right, it wasn't in the first standard, but as an add on.
<beach>
Yes, and that was good for existing implementations. But SICL is not one of those, so we have more freedom.
<jackdaniel>
beach: I don't see the relation between statiation and being bootstrapped from full-ANSI Common Lisp implementation
<jackdaniel>
in fact clasp's clos, that is based on pcl, has satiation implemented by Bike
<beach>
jackdaniel: You are probably right.
<beach>
Well, let's see...
<beach>
Satiation can certainly be implemented in any CLOS implementation.
<beach>
But to do it at bootstrapping time to avoid metastability issues seems to require that the mechanism already work then.
treflip has joined #commonlisp
Oladon has joined #commonlisp
<beach>
So if you take an existing pre-ANSI Common Lisp implementation, bootstrap it fully, and only then add PCL, I think you can't avoid the metastability issues, and you need to special-case them. I may be wrong of course.
<beach>
Actually, you probably only need FUNCALLABLE-STANDARD-OBJECT to make it work.
<jackdaniel>
afair clasp (and you need to ask Bike for details) does it this way: methods are defined as functions and then they are prompted to generic functions and satiated
<beach>
Because with FUNCALLABLE-STANDARD-OBJECT, you can implement your own dispatch mechanism in any Common Lisp implementation.
<beach>
"promoted"?
<jackdaniel>
coerced? installed? ansi cl glossary doesn't have a name for this technique for sure
<jackdaniel>
redefined to be a generic function, with the old function being its primary methods
<beach>
Sure, again, satiation is general. But using it at bootstrapping time to prevent metastability issues is more specific.
<Bike>
that is indeed how clasp does it
<beach>
Perhaps Clasp gets away with it because it has two preceding Clasp implementations which have CLOS.
<jackdaniel>
ecl doesa similar thing, but doesn't introduce a concept of satiation, just sets the funcallable function for the generic function (with added type checks), and that's how metastability is solved there
<jackdaniel>
only compute-applicable-methods{-using-classes} requires special handling in a case these are redefined
<jackdaniel>
but I think that this applies to all implementations
<jackdaniel>
beach: ecl does something similar without two preceding clasp implementations (and without satiation, as noted above)
<beach>
jackdaniel: But either the initial discriminating function is empty, in which case you have metastability issues, or it is somehow fully functional, so you must have used some mechanism to fill it with relevant effective methods.
<jackdaniel>
if you have only a single function, say (defun add-method (…) …), then
<jackdaniel>
then when you add another method, then it is "properly" recomputed
<beach>
Yes, I see.
<jackdaniel>
and there is only a handful of "early methods" that needs such trick to be performed only once
<beach>
That makes sense.
<Bike>
"Perhaps Clasp gets away with it because it has two preceding Clasp implementations which have CLOS." it doesn't. at this point clasp only has one clos implementation
<Bike>
(thankfully)
<beach>
And in the worst case, if you have two methods, you can write a small special function to select which one.
<beach>
Heh, OK.
<jackdaniel>
having two methods would not work, because if it is a function then it can't have two methods
<jackdaniel>
non-generic function* (initially)
<Bike>
for a while we had it going so that the old ecl-derived implementation was in place during bootstrapping, but i cleared that out because it was silly
cage has joined #commonlisp
<beach>
No, I mean, if the AMOP says that some generic function has two standard methods, then you could implement each one as a function, and define a new small function to choose between the two and set that new function to the discriminating function.
<jackdaniel>
ah, yes, if that were necessary before functions are "fixed" then we could do that
<beach>
Bike: Implementation of CLOS?
<Bike>
the old ecl-derived implementation of CLOS, yes
<beach>
And what does the current CLOS implementation look like?
<beach>
I must have missed that you created a better one for Clasp.
<Bike>
eh? i mean, it's the one based on your papers here
<jackdaniel>
I think that what Bike says that the old Clasp CLOS implementation required CLOS in place
<beach>
Bike: Right, of course.
<beach>
I guess it looks more like the SICL implementation, which I suppose it kind of has to if you use fast generic dispatch and the other techniques.
<Bike>
Right
<beach>
That makes me wonder whether this implementation could be usefully extracted to a separate repository.
<Bike>
hmm. parts of it maybe, like the actual code generator for discriminating functions maybe could be, except clasp has to do some stuff there specific to its runtime
<beach>
Yeah, there might be some non-trivial configuration required.
<beach>
Still, it might be worth contemplating.
<Bike>
i think jackdaniel's implementation is probably smarter than mine about merging paths, so it would be nice to be able to use it
<beach>
"merging paths"?
<jackdaniel>
you may have the same effective method for two distinct paths in the binary tree
<beach>
Ah, that. Yes.
<jackdaniel>
if class numbers are adjacent, then you may reduce number of tests
<beach>
Also, the SICL implementation has a lot of methods that trampoline to functions, because early on I thought that would be necessary. And the technique of setting the discriminating function would require a separate function. But it is kind of ugly if it is not required, and I don't think it is required.
<beach>
jackdaniel: I think SICL has that optimization. Or at least it was meant to.
Th30n has quit [Quit: WeeChat 3.5]
<jackdaniel>
I see
<jackdaniel>
another optimization is that the order of arguments tested may also influence overal number of tests, but I'm on a different computer so I don't have the description handy
<beach>
Anyway, interesting discussions here today. I will give some more thought to possibly extracting all or part of a SICL-like CLOS implementation to a separate repository.
taiju` is now known as taiju
<beach>
jackdaniel: Yes, I thought of that too, but didn't do anything about it.
<beach>
You can in fact test the arguments in any order, no matter the argument precedence order, as long as you don't violate that one.
<jackdaniel>
another one (and I think that SICL does not implement that), is smart ordering of EQL specializer tests - one specialization excludes some EQL specializations on another argument
<beach>
Right.
<beach>
I have not optimized EQL specializers yet.
<beach>
rotateq: This is your opportunity to fame! Create a separate repository with a new implementation of CLOS that uses all the techniques discussed here and in papers. :)
<jackdaniel>
what would be a purpose of such excercise? - except for gaining fame of course,)
<rotateq>
beach: I'm not so much into fame but I know you intend it. :) And believe in me more than I do.
<beach>
Same as I always keep thinking of, decrease the combined maintenance burden.
<beach>
jackdaniel: Then I could remove lots of code from SICL, and hopefully the same could be done in Clasp and ECL.
<rotateq>
Are there restrictions on EQL specializers? They make sense for fixed objects like numbers, characters, symbols, what else?
<jackdaniel>
they may be also standard objects
<jackdaniel>
basically anything externalizable
<rotateq>
But okay let me log what was written here the last minutes so it won't be lost if I need it again.
<beach>
I don't think there is even a restriction on externalize.
<rotateq>
And what does externalizable mean in this context specifically?
<jackdaniel>
when you compile a file with a method with an eql-specializer, then you need to store the object in the fasl
<beach>
Right, but you can create an EQL specializer at run time without file compilation.
<rotateq>
Ah now it gets more clear.
<jackdaniel>
yes, but then you can't compile a file with such method. so perhaps the phrasing was a bit off, but it is certainly a limitation of eql-specializers
<rotateq>
beach: and hopefully the semantics of the sentence above was not misread, due to one word wasn't typed "... but I know how you intend it."
<beach>
Sure.
<beach>
Let me say this again, very interesting discussion here today.
<beach>
I learned some new things.
<rotateq>
It's sympathic to hear that from an expert. :)
<beach>
You vastly overestimate my expertise.
waleee has quit [Quit: WeeChat 3.5]
<rotateq>
Then let's say I hope to be present in persona at next ELS or another such opportunity.
<beach>
Great! Do we have confirmation that it will be in Amsterdam? That would be fantastic.
Oladon has quit [Quit: Leaving.]
<rotateq>
Oh that would be way nearer to where I live. And I would also take days off from classes, which would hopefully just count as continuing education.
<beach>
Students have even been known to get a contribution from their university for travel expenses.
<beach>
Don't hesitate to ask them.
<beach>
Certainly, teachers can get such a contribution.
rainthree has joined #commonlisp
<rotateq>
I'm not in a university right now, but as I'm one of the best it would be okay I guess, with a good explanation.
<rotateq>
*university context
<beach>
Oh, I see.
kpoeck has quit [Quit: kpoeck]
fitzsim has quit [Remote host closed the connection]
fitzsim has joined #commonlisp
pslotko has joined #commonlisp
prokhor_ has quit [Quit: Leaving]
prokhor_ has joined #commonlisp
pslotko has quit [Quit: Leaving]
taiju has quit [Ping timeout: 250 seconds]
infra_red[m] has joined #commonlisp
pslotko has joined #commonlisp
jack_rabbit has joined #commonlisp
knusbaum has quit [Ping timeout: 244 seconds]
Bike has quit [Quit: Connection closed]
analogsalad has joined #commonlisp
prokhor__ has joined #commonlisp
prokhor_ has quit [Remote host closed the connection]
azimut has quit [Remote host closed the connection]
azimut has joined #commonlisp
karlosz has joined #commonlisp
Oladon has joined #commonlisp
waleee has joined #commonlisp
treflip has quit [Remote host closed the connection]
tyson2 has quit [Remote host closed the connection]
<Guest74>
lechner: yes, what you see is correct. setf takes a list of pairs of place and new value.
<Guest74>
They're answering the question you actually asked, which is something different.
<Guest74>
s/actually/literally/
<Guest74>
shouldn't have said list either, just one or more pairs.
<lechner>
and i thought haskell was complicated!
<drakonis>
ha
<lechner>
Guest74: thanks!
<drakonis>
haskell is complicated!
<lechner>
drakonis: Hi, and thanks!
<drakonis>
CL is more like a kitchen sink with lots of warts that can be papered over with the libraries
<drakonis>
lots and lots of those too
<drakonis>
#'values as i understand is used for dealing with multiple output
<lechner>
it's just my imprecise use of language. i am still processing place n. 1. a form which is suitable for use as a generalized reference. 2. the conceptual location referred to by such a place[1].
<mfiano>
This channel assumes some basic CL knowledge. For more beginner friendly help, see #clschool
<mfiano>
I took your question literally, as "values" means something different in the standard.
Bike has joined #commonlisp
<lechner>
mfiano: no worries, and thanks! TIL
Guest74 has quit [Quit: Connection closed]
tyson2 has joined #commonlisp
aartaka has quit [Ping timeout: 276 seconds]
aartaka has joined #commonlisp
<rotateq>
lechner: Haskell has grown in complexity over the years. :)
<rotateq>
Ah so you meant to do (setf a b c d ...)?
<rotateq>
As that might compile to (progn (setf a b) (setf b d) ...) and signals an error if number of operands is odd.
<rotateq>
ack sry, of course (progn (setf a b) (setf c d) ...)!
paule32__ is now known as paule32
<rotateq>
mfiano: As I came from Haskell before CL and it uses tuples to return multiple values, I started to see it similar. And one can use VALUES in a type signature declaration too with being more specific if needed and useful.
karlosz has joined #commonlisp
tyson2 has quit [Remote host closed the connection]
alvaro121_ has joined #commonlisp
alvaro121 has quit [Ping timeout: 255 seconds]
trev has quit [Quit: trev]
karlosz has quit [Ping timeout: 244 seconds]
rainthree has quit [Read error: Connection reset by peer]
Oladon has quit [Quit: Leaving.]
jmdaemon has joined #commonlisp
tyson2 has joined #commonlisp
orestarod has quit [Quit: Leaving]
livoreno has joined #commonlisp
makomo has joined #commonlisp
cage has quit [Quit: rcirc on GNU Emacs 27.1]
analogsalad has quit [Quit: bye]
Dynom has quit [Quit: WeeChat 3.5]
orestarod has joined #commonlisp
Oddity has joined #commonlisp
Guest74 has joined #commonlisp
anticomputer has quit [Remote host closed the connection]