eddof13 has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
tyson2 has joined #commonlisp
Fare has joined #commonlisp
<jmercouris>
There is one thing that has always eluded me
<jmercouris>
given a list like this '((:salmon "turkey"))
<jmercouris>
I always do (find :salmon '((:salmon "turkey")) :key #'car)
<jmercouris>
is there a better way? some function I'm not aware of?
<aeth>
there is only one thing that has always eluded me, that... and off by one errors
<aeth>
jmercouris: first thing that comes to mind is that it's an alist
<jmercouris>
like there is getf for plist
<aeth>
well, close enough to an alist anyway
<aeth>
it's an alist with (list "turkey") as the value
<jmercouris>
aeth: right, but is there a good function that does what I am doing with find?
<aeth>
(assoc :salmon '((:salmon "turkey")))
<aeth>
seems to produce the same result
<jmercouris>
assoc, FUCK YES
<jmercouris>
I KEEP FORGETTING
<jmercouris>
thank you, I've written it a million times in a past life
<aeth>
to be fair, alists are mostly a Scheme thing
<jmercouris>
I forgot that I used that a ton in code that uses clack
<jmercouris>
it's so hard to keep all of common lisp in my head
<jmercouris>
and there are so many styles to write code in
<aeth>
yes
<aeth>
every now and then I do a cleanup pass over my code
Fare has quit [Ping timeout: 260 seconds]
blop_ has joined #commonlisp
<aeth>
because it's easy to do things not quite idiomatically
<jmercouris>
that's what I am saying, there is not a true "idiomatic" way
<jmercouris>
one might prefer extensive usage of lists, another of objects
<jmercouris>
like Fukamachi for example uses lists a lot
blop has quit [Remote host closed the connection]
<jmercouris>
which is why I used assoc in Clack interfacing code
<aeth>
if you're really clever you can use 2D arrays
<jmercouris>
i'm not sure that is worth the inflexiblity
<jmercouris>
there are cases of course...
<aeth>
right, would only make sense if you're not adding/removing elements
<aeth>
or if you want to overallocate in the start like in a game engine, but only for numerical arrays
<jmercouris>
yes
tyson2 has quit [Remote host closed the connection]
kevingal has quit [Remote host closed the connection]
kevingal_ has quit [Remote host closed the connection]
ryanbw has quit [Ping timeout: 245 seconds]
zaymington has joined #commonlisp
masinter has quit [Remote host closed the connection]
blop_ has quit [Remote host closed the connection]
bendersteed has joined #commonlisp
bendersteed has quit [Remote host closed the connection]
hernan has quit [Remote host closed the connection]
zaymington has quit [Ping timeout: 255 seconds]
rtypo has quit [Ping timeout: 255 seconds]
anticrisis has quit [Read error: Connection reset by peer]
anticrisis has joined #commonlisp
LW has joined #commonlisp
attila_lendvai has joined #commonlisp
LW has quit [Client Quit]
pranavats has joined #commonlisp
zaymington has joined #commonlisp
rgherdt has joined #commonlisp
azimut has quit [Ping timeout: 252 seconds]
Cymew has joined #commonlisp
rgherdt_ has joined #commonlisp
Lord_Nightmare has quit [Ping timeout: 240 seconds]
rgherdt has quit [Ping timeout: 272 seconds]
chomwitt has joined #commonlisp
attila_lendvai has quit [Ping timeout: 264 seconds]
zaymington has quit [Remote host closed the connection]
zaymington has joined #commonlisp
habamax has joined #commonlisp
rgherdt__ has joined #commonlisp
rgherdt_ has quit [Remote host closed the connection]
shka has joined #commonlisp
pranavats has left #commonlisp [Disconnected: Hibernating too long]
jello_pudding has quit [Ping timeout: 260 seconds]
jello_pudding has joined #commonlisp
Pixel_Outlaw has quit [Quit: Leaving]
attila_lendvai has joined #commonlisp
attila_lendvai has quit [Ping timeout: 264 seconds]
pve has joined #commonlisp
igemnace has joined #commonlisp
Inline has quit [Quit: Leaving]
notzmv has quit [Ping timeout: 272 seconds]
bendersteed has joined #commonlisp
Inline has joined #commonlisp
pranavats has joined #commonlisp
shka has quit [Remote host closed the connection]
shka has joined #commonlisp
_cymew_ has joined #commonlisp
ryanbw has joined #commonlisp
silasfox has joined #commonlisp
ns12 has joined #commonlisp
<ns12>
Is the Common Lisp interpreter fully programmable? If so, does it mean that I can modify its lexer and parser to interpret a whole different programming language such as Python?
<beach>
Wow, hold on a bit...
<beach>
First of all, whether it is an interpreter or a compiler is not specified.
<aeth>
ns12: Common Lisp has reader macros, so, yes, you could implement all of Python as a reader macro. Lexer/parser isn't really the way Lisps work. They work with "readers".
<beach>
Second, the lexer and the parser is the READ function. It is kind of programmable, but it remains a sort of recursive descent. You can program it to dispatch on the first one or two characters, but you can't program it to be an LR parser.
<beach>
Third, whether a different programming language could be emulated does not depend just on syntax, but a lot on semantics as well. In most cases, you would have to write a complete implementation of that other language.
<ns12>
"You can program it to dispatch on the first one or two characters" - Is that a limitation of the API provided by Common Lisp?
<beach>
It is what READ does, as aeth mentioned.
<beach>
You can of course create a different parser that generates S-expressions.
<aeth>
beach: technically, I think you could just call out to a compiler as a separate program so you wouldn't need to write a complete implementation of another language, but it would be a very disappointing way to do it and the integration with CL probably wouldn't be great
<aeth>
s/a compiler/another compiler/
<beach>
aeth: Why are you telling me this?
<aeth>
(or, at least, if CL's being compiled)
dino_tutter has joined #commonlisp
<beach>
ns12: For the first characters, see SET-MACRO-CHARACTER and SET-DISPATCH-MACRO-CHARACTER.
<ns12>
Okay. Thanks.
<beach>
ns12: What made you think that Lisp uses an interpreter?
<beach>
ns12: I am asking because there is this (incorrect) line of thought that makes people think Lisp is slow, which is interactive => interpreted => slow.
<ns12>
Nothing in particular. Sloppy language use perhaps. I am aware that the Common Lisp implementation that I use (SBCL) uses a compiler.
<beach>
OK.
<edgar-rft>
ns12: There were Common Lisp implementations of the Python programming language like https://clpython.common-lisp.dev/ where one could look what they did if that helps
<ixelp>
CLPython - an implementation of Python in Common Lisp
mgl has joined #commonlisp
zaymington has quit [Remote host closed the connection]
Lord_Nightmare has joined #commonlisp
Gleefre has joined #commonlisp
<beach>
ns12: What was the reason for your initial question? Were you asked by someone else, or did you come up with it yourself?
rainthree has joined #commonlisp
<beach>
ns12: You don't have to answer if you don't want to. I am just curious.
anticrisis has quit [Read error: Connection reset by peer]
pfdietz has quit [Quit: Client closed]
notzmv has joined #commonlisp
rogersm has joined #commonlisp
seanw has joined #commonlisp
tertek has quit [Quit: %quit%]
lucerne has quit [Ping timeout: 246 seconds]
chomwitt has quit [Ping timeout: 264 seconds]
lucerne has joined #commonlisp
tertek has joined #commonlisp
random-nick has joined #commonlisp
gxt has quit [Ping timeout: 252 seconds]
gxt has joined #commonlisp
pfdietz has joined #commonlisp
pve has quit [Ping timeout: 255 seconds]
pve has joined #commonlisp
tertek has quit [Quit: %quit%]
msavoritias has joined #commonlisp
tertek has joined #commonlisp
prokhor has joined #commonlisp
jonatack has quit [Read error: Connection reset by peer]
jonatack has joined #commonlisp
Gleefre has quit [Remote host closed the connection]
Gleefre has joined #commonlisp
pfdietz has quit [Quit: Client closed]
edgar-rft has quit [Remote host closed the connection]
edgar-rft has joined #commonlisp
yitzi has joined #commonlisp
chomwitt has joined #commonlisp
NicknameJohn has joined #commonlisp
blop_ has joined #commonlisp
shka has quit [Read error: Connection reset by peer]
shka has joined #commonlisp
rtypo has joined #commonlisp
jjnkn has joined #commonlisp
wonko-the-sane has quit [Remote host closed the connection]
<jcowan>
Racket is not CL, of course, but it does have a fully replaceable "front end"; it ships with an Algol 60 reader that generates Scheme along with several other languages. You can begin a file with "#lang algol60", and there are macros include-algol and literal-algol. the result of which is a zero-argument procedure corresponding to an Algol 60 program.
<jcowan>
In principle there is no reason why a CL implementation should not have a global variable *read-procedure* or a macro with-read-procedure.
<jcowan>
s/procedure/function//g
<beach>
To return a zero-argument function corresponding to an Algol 60 program would require a "read function" that does way more things than just read Algol 60 code.
<beach>
That was the point communicated to ns12, i.e., that someone would have to implement the parser and the translator from the language being processed to the host language.
pve has quit [Quit: leaving]
habamax has quit [Remote host closed the connection]
<jcowan>
That's what it *does*, but its interface is that of read (or more accurately a Racket-specific variant of it).
<beach>
Besides, the Common Lisp READ function returns code to be compiled, not a function to be executed. So this hypothetical read function would not be a substitute for READ. It would be a substitute for READ+COMPILE.
<jcowan>
The functions I mentioned above are as you say. You can also get access to the Algol 60 reader if you want.
<jcowan>
However, the COMPILE part is the ordinary one, not specific to A60 in any way.
<beach>
That sounds very strange to me. It would imply that Algol 60 code can be expressed as source code in the host language without any semantic analysis or transformation.
<Demosthenex>
jcowan: no idea, i just had to add a food reference
pve has joined #commonlisp
lottaquestions_ has quit [Quit: Konversation terminated!]
<jcowan>
Semantically A60 is very close to Scheme, or CL for that matter. But in principle it makes no difference. It just means that more work is done in the reader.
<jcowan>
Something I would like to know about is how EQ hash tables operate in the face of moving garbage collectors. Is the GC generally aware of the internals of hash tables?
<beach>
If the hash function is based on the address of the key, then yes, an invocation of the garbage collector must be followed by a re-hash.
<jcowan>
Sure. So which is usual: basing the hash function on something other than the address, or having the GC do the rehash, or rehashing lazily on the next access, or something else. I'm looking for general implementer guidance here, not a quantitative reply.
<beach>
I would go for a non-moving collector, but I take it that's not an option.
blop_ has quit [Ping timeout: 252 seconds]
blop_ has joined #commonlisp
<beach>
Anyway, hayley has studied the subject in detail, so can probably provide more pros and cons.
<hayley>
The SBCL GC sets a flag in a hash table when it moves a key of the hash table.
<beach>
Garbage collection arguments are usually full of compromises in different areas, and one of the arguments to me is that moving objects requires lots of memory operations that are not necessarily localized. And it probably is not great for the cache either.
<hayley>
Indeed the collector is aware of the internals of a hash table; there is also some effort made in gencgc to avoid rehashing, by checking if the hash function and keys would require any address-based hashing.
<hayley>
My mark-region collector always triggers rehashing, but it avoids moving objects, so rehashing is already rare.
<beach>
The argument against a non-moving collector is usually fragmentation, but I believe in the arguments in the publications by Paul Wilson, the essence of which is "objects that are allocated together, die together". Theoretical results about fragmentation often assume some randomness, and Wilson argues that only programs that do nothing interesting behave like tat.
<mgl>
hayley: I don't get that.
<hayley>
beach: In testing I found my non-moving collector to scale better than the parallel copying collector in OpenJDK. But I'm not entirely sure if I managed to get OpenJDK to act similarly enough to SBCL in when it triggers a collection.
<hayley>
Both collectors seem to run out of bandwidth at some point, but mine runs out later.
<beach>
hayley: Great!
<mgl>
hayley: "avoid moving objects" and "always triggers rehashing"?
<hayley>
mgl: mark-region always triggers a rehash when it moves a key, whereas gencgc performs additional checks to decide if a rehash is necessary when moving a key.
<mgl>
hayley: You mean mark-region does not consider the address-based-p flag on the key being moved?
<hayley>
Right. I probably should check the flag; gencgc does some more checks though.
<mgl>
Yes, that may very well be quite good for performance unless moves are really rare.
<hayley>
Moves are indeed rare. I compact infrequently and I compact only a small part of the heap at a time.
<hayley>
beach: My collector does fragment an interesting amount, but that is typical of a mark-region collector (rather than a mark-sweep collector).
<beach>
I see.
<mgl>
hayley: So rehashing is triggerred if it's an EQ hash table and any key moves?
<hayley>
Rehashing is triggered if any key moves. I don't check for the kind of hash table. Yes, it's very lazy of me.
<mgl>
Ouch.
<hayley>
In practise I find that compaction is done at most in 15% of collections, and it only moves objects on pages which are used sparsely.
<hayley>
(It's also backwards to most generational collectors: I never compact in nursery collections, and might compact in tenured collections. I haven't tested this policy against others.)
<mgl>
Ah, okay. Non-EQ hash table can have addressed based keys as well.
jonatack has quit [Read error: Connection reset by peer]
jonatack has joined #commonlisp
lottaquestions_ has joined #commonlisp
NicknameJohn has quit [Ping timeout: 272 seconds]
<hayley>
At the moment I haven't heard of rehashing causing any performance regressions. So far the biggest issue is the lack of support for immobile space (which now isn't a great name), as the immobile space stores layouts which may be referenced using 32-bit pointers, which saves a word in the header of each instance.
<ns12>
beach: "What was the reason for your initial question?" - I came up with it myself. I was aware that the readtable can be modified, so I wondered whether or not it is possible to modify it to the point where the Common Lisp implementation turns into an implementation of another programming language.
<beach>
ns12: Got it.
tyson2 has joined #commonlisp
knusbaum has quit [Ping timeout: 240 seconds]
Cymew has quit [Ping timeout: 272 seconds]
rainthree has quit [Ping timeout: 255 seconds]
tyson2 has quit [Remote host closed the connection]
knusbaum has joined #commonlisp
cage has joined #commonlisp
cage has quit [Excess Flood]
cage has joined #commonlisp
cage has quit [Excess Flood]
silasfox has quit [Read error: Connection reset by peer]
cage has joined #commonlisp
jjnkn has quit [Ping timeout: 258 seconds]
silasfox has joined #commonlisp
silasfox has quit [Ping timeout: 255 seconds]
NicknameJohn has joined #commonlisp
lottaquestions has joined #commonlisp
lottaquestions_ has quit [Quit: Konversation terminated!]
lottaquestions has quit [Client Quit]
lottaquestions has joined #commonlisp
igemnace has quit [Read error: Connection reset by peer]
NicknameJohn has quit [Ping timeout: 255 seconds]
igemnace has joined #commonlisp
yitzi has quit [Remote host closed the connection]
rgherdt__ has quit [Ping timeout: 264 seconds]
phantomics has quit [Remote host closed the connection]
dino_tutter has quit [Ping timeout: 255 seconds]
Gleefre has quit [Remote host closed the connection]
Gleefre has joined #commonlisp
kevingal has joined #commonlisp
luna-is-here has quit [Ping timeout: 252 seconds]
luna-is-here has joined #commonlisp
bendersteed has quit [Quit: bendersteed]
justache has quit [Ping timeout: 258 seconds]
justache has joined #commonlisp
remexre has quit [Ping timeout: 245 seconds]
remexre has joined #commonlisp
iska has quit [Ping timeout: 245 seconds]
iska has joined #commonlisp
mathrick has quit [Ping timeout: 252 seconds]
mathrick has joined #commonlisp
igemnace has quit [Remote host closed the connection]
xantoz has quit [Ping timeout: 245 seconds]
_cymew_ has quit [Remote host closed the connection]
xantoz has joined #commonlisp
amoroso has joined #commonlisp
makomo has quit [Quit: WeeChat 4.0.4]
makomo has joined #commonlisp
amoroso has quit [Client Quit]
dim has quit [Ping timeout: 258 seconds]
dim has joined #commonlisp
jaimelm has quit [Ping timeout: 258 seconds]
jaimelm has joined #commonlisp
<jcowan>
The reason for non-moving collectors AFAIK is conservatism (i.e. you do not know all the roots). A precise non-moving GC can't be generational, which seems wrong.
cognemo has quit [Ping timeout: 252 seconds]
hernan has joined #commonlisp
cognemo has joined #commonlisp
pfdietz has joined #commonlisp
tyson2 has joined #commonlisp
yitzi has joined #commonlisp
lottaquestions has quit [Quit: Konversation terminated!]
lottaquestions has joined #commonlisp
<beach>
I don't think that's true. A generational collector doesn't necessarily keep a generation in consecutive locations in memory.
<beach>
I believe that in Wilson's survey paper, he talks about something that I think is called a "fake moving collector", or something similar. That paper is quite good. But perhaps the Garbage Collection Handbook mentions it too.
sloanr has joined #commonlisp
azimut has joined #commonlisp
tyson2 has quit [Remote host closed the connection]
dino_tutter has joined #commonlisp
kstuart has quit [Remote host closed the connection]
sloanr has quit [Ping timeout: 252 seconds]
kstuart has joined #commonlisp
jjnkn has joined #commonlisp
rainthree has joined #commonlisp
jonatack has quit [Quit: WeeChat 4.0.4]
NicknameJohn has joined #commonlisp
jonatack has joined #commonlisp
rainthree has quit [Ping timeout: 255 seconds]
kevingal has quit [Ping timeout: 260 seconds]
tyson2 has joined #commonlisp
pfdietz has quit [Ping timeout: 245 seconds]
amb007 has quit [Ping timeout: 260 seconds]
NicknameJohn has quit [Read error: Connection reset by peer]
jjnkn has quit [Quit: leaving]
jonatack has quit [Quit: WeeChat 4.0.5]
jonatack has joined #commonlisp
kevingal has joined #commonlisp
msavoritias has quit [Remote host closed the connection]
rainthree has joined #commonlisp
rainthree has quit [Ping timeout: 272 seconds]
pfdietz has joined #commonlisp
akoana has joined #commonlisp
kevingal_ has joined #commonlisp
Gleefre has quit [Remote host closed the connection]
Gleefre has joined #commonlisp
tyson2 has quit [Remote host closed the connection]
lagash has quit [Ping timeout: 260 seconds]
Gleefre has quit [Remote host closed the connection]
alphacentauri has quit [Quit: WeeChat 4.0.5]
Gleefre has joined #commonlisp
alphacentauri has joined #commonlisp
cage has quit [Quit: rcirc on GNU Emacs 29.1]
amb007 has joined #commonlisp
waleee has joined #commonlisp
Gleefre has quit [Remote host closed the connection]
Gleefre has joined #commonlisp
anticrisis has joined #commonlisp
jrm has quit [Quit: ciao]
<jcowan>
beach: pointer to "Wilson's survey paper"?
jrm has joined #commonlisp
Gleefre has quit [Remote host closed the connection]
jrm has quit [Remote host closed the connection]
Gleefre has joined #commonlisp
alphacentauri has quit [Read error: Connection reset by peer]
alphacen1 has joined #commonlisp
jrm has joined #commonlisp
Gleefre has quit [Remote host closed the connection]
Gleefre has joined #commonlisp
NicknameJohn has joined #commonlisp
yitzi has quit [Remote host closed the connection]
shka has quit [Ping timeout: 255 seconds]
NicknameJohn has quit [Ping timeout: 248 seconds]
rgherdt__ has joined #commonlisp
moon-child has joined #commonlisp
<moon-child>
is there any way to manually control accessor names for structs? I want to make a struct with gensym slot names, but it seems there is not any way to avoid possible collision in the accessors
<mfiano>
What is wrong with :conc-name "" (not :conc-name nil, which is simular but slightly different) ?
<mfiano>
or maybe simlar
<moon-child>
hmmm, conc-name nil would allow gensym accessors, but mess up the constructor and slot-value. I can make my own constructor, and slot-value is not too important. Thanks!
<mfiano>
:conc-name nil can possibly have surprising/unintended results when used in combination with :include. For that reason I recommend ""
lagash has joined #commonlisp
pve has quit [Quit: leaving]
<moon-child>
I don't think "" has the desired effect
<mfiano>
I am too tired, but just know that nil will not inherit the package symbols of an included struct, whereas "" will. You could be accessing the wrong accessor (and have an additional one/slot that wasn't intended)
<mfiano>
(or something along those lines, again, too tired)
<moon-child>
I see, that makes sense. I think I will just disallow including structs, then. And perhaps provide an alternate path to standard objects and classes, for more expressive such behaviour
<mfiano>
similar. there, third time's a charm, and i am off.
reb has quit [Remote host closed the connection]
Gleefre has quit [Remote host closed the connection]
Gleefre has joined #commonlisp
eddof13 has joined #commonlisp
akoana has quit [Quit: leaving]
eddof13 has quit [Ping timeout: 258 seconds]
rgherdt__ has quit [Quit: Leaving]
<hayley>
jcowan: "A precise non-moving GC can't be generational, which seems wrong." My collector would fit the bill, if you remove conservative root handling.
<jcowan>
hayley: Okay (and yes, conservative and precise are opposed, so that's no problem). But if objects are not being moved into compact regions, how do you keep track of what generation an object is in, and how do you efficiently find space in garbage generations?
<hayley>
I assign generations to 128-byte "lines", which is the smallest granule I can allocate.
Pixel_Outlaw has joined #commonlisp
<hayley>
Boehm's sticky marking scheme could also work in a precise context, too; I recall something of the sort being used for Java as a concurrent generational collector.