<beach>
I can't see how it can be avoided in general to have duplicate elements in the result if either LIST-1 or LIST-2 has duplicate elements.
<hayley>
It doesn't seem to matter, given "If either list-1 or list-2 has duplicate entries within it, the redundant entries might or might not appear in the result."
<beach>
Removing such duplicates would require that the :TEST or :TEST-NOT function be applied to two elements of the same list, and the specification of UNION does not consider this possibility.
<beach>
Yes, but why does it say "might or might not" rather than "will definitely"?
<edwlan[m]>
well, if you use TEST to compare A1 from LIST-1 and A from LIST-2 and choose the element from LIST-2, then compare A2 from LIST-1 and A from LIST-2 and choose the element from LIST-2, you'd only emit A from LIST-2 once
<edwlan[m]>
And so deducplicate
<beach>
Oh, wait, I see it.
<beach>
Yes, thank you!
jonatack has quit [Quit: WeeChat 3.8]
<beach>
So duplicates in LIST-1 that do not appear in LIST-2 will appear in the result, but not necessarily otherwise.
pve has joined #commonlisp
<edwlan[m]>
Yeah
<beach>
Wow, we really need to start working on the planned web site "Common Lisp for language implementers". :)
<edwlan[m]>
I also wonder if the standard wants to give some leeway for implementations to helpfully generate an actual set where no two items in the result are equal under TEST
<edwlan[m]>
So, that's not specified behavior but implementation-defined behavior
<beach>
Possibly. But this would work only if the :TEST or :TEST-NOT can be applied to two elements of the same list. It is not clear to me that the specification of UNION allows that.
<edwlan[m]>
Yeah, it's a bit ambiguous on that question
<beach>
On the other hand, for a symmetric function without side effects, there would be no way to detect such a situation.
<flip214>
edwlan[m]: you could submit a patch for alexandria-2 for such a function... though it might generalize to multiple lists, as just putting everything in a hash table might be the easiest way to do that
<beach>
flip214: You can't do that in general.
<edwlan[m]>
That wording does allow for optimizations for known TEST functions
<edwlan[m]>
Like, if you know that the test is EQUAL, you can use SXHASH to avoid comparing duplicate elements with every element of the other list
<beach>
I suspect there would have to be restrictions on the KEY function as well.
_cymew_ has joined #commonlisp
<pjb>
beach: if you go thru hash-tables, you would uniquify duplicates.
<beach>
pjb: But you can't do that in general is what I was just saying.
jonatack has joined #commonlisp
<pjb>
or any other intermediate representation for the set that doesn't allow duplicates.
<beach>
pjb: But you can't do that in general is what I was just saying.
<pjb>
Yes, it's allowed, for the trivial algorithm using just the input list.
<pjb>
Which is good enough also for small lists/sets.
<edwlan[m]>
you'd have to support hash-tables for arbitrary tests
<beach>
pjb: Like I said, there must be restrictions on the KEY function as well.
<edwlan[m]>
If test is equal, you'd do (setf (gethash (key el) ht) el) to deduplicate, right?
<edwlan[m]>
(or a supported hash-table test)
<beach>
edwlan[m]: There would have to be restrictions on the KEY function as well.
<beach>
Imagine a KEY function such as (lambda (element) (if (consp element) (car element) element))
<beach>
I am sure I can come up with a KEY function for which the hash table idea won't work.
<edwlan[m]>
I don't see how, as long as the key function is deterministic
<pjb>
I don't think that the key function be a factor here (assuming it respects the rules for key functions). The important thing is indeed the TEST for the hash-table test.
<beach>
Y'all may be right. Let me think about it some more.
<pjb>
The operators could scan the lists first, O(n+m), to check for the type and range of keys. Then other than hash-tables could be used, say bit-vectors if all the keys are integers in a "small" range.
<edwlan[m]>
I can't find anywhere in the standard that rules out a :key like (lambda (_) (random 5))
<pjb>
beach: but in general, it's not an objective to avoid duplicates. If it was, it would be trivial to use remove-duplicates.
<pjb>
However, a random or non-pure function key is bound to lead to undefined behavior; notably, it's specifically not specified if keys are applied more than once on each element, so if they don't return the same value for the same element, you know you're in for some pain.
<beach>
More evidence that we need that web site.
<pjb>
beach: the question of duplicates in set operations is more that it's allowed to return results with some duplicates removed, depending on the data structure and algorithm used. Notably, only duplicates from one list could be removed…
dcb has quit [Quit: MSN Messenger 3.8]
shka has joined #commonlisp
jrm has quit [Quit: ciao]
jrm has joined #commonlisp
lucasta has joined #commonlisp
rgherdt has joined #commonlisp
semz has quit [Quit: ZNC 1.8.2+deb2build5 - https://znc.in]
semz has joined #commonlisp
soundmodel has joined #commonlisp
trev has joined #commonlisp
thonkpod has quit [Ping timeout: 260 seconds]
thonkpod has joined #commonlisp
jonatack has quit [Quit: WeeChat 3.8]
wilfred has quit [Quit: Connection closed for inactivity]
Lord_of_Life has quit [Ping timeout: 246 seconds]
Lord_of_Life has joined #commonlisp
soundmodel has quit [Ping timeout: 245 seconds]
Brucio-61 has quit [Ping timeout: 260 seconds]
attila_lendvai has joined #commonlisp
kaskal has quit [Ping timeout: 248 seconds]
kevingal has joined #commonlisp
scymtym has joined #commonlisp
Brucio-61 has joined #commonlisp
kaskal has joined #commonlisp
attila_lendvai has quit [Ping timeout: 240 seconds]
_cymew_ has quit [Ping timeout: 240 seconds]
greaser|q has joined #commonlisp
greaser|q has joined #commonlisp
greaser|q has quit [Changing host]
greaser|q is now known as GreaseMonkey
Lycurgus has quit [Quit: Exeunt: personae.ai-integration.biz]
rgherdt has quit [Ping timeout: 264 seconds]
samebchase has quit [Read error: Connection reset by peer]
samebchase has joined #commonlisp
soundmodel has joined #commonlisp
lucasta has quit [Quit: Leaving]
rgherdt has joined #commonlisp
poselyqualityles has quit [Remote host closed the connection]
poselyqualityles has joined #commonlisp
cage has joined #commonlisp
glaucon has joined #commonlisp
soundmodel has quit [Ping timeout: 245 seconds]
soundmodel has joined #commonlisp
kevingal has quit [Ping timeout: 240 seconds]
glaucon has quit [Quit: Leaving.]
Gleefre has quit [Remote host closed the connection]
random-nick has joined #commonlisp
soundmodel has quit [Ping timeout: 245 seconds]
avocadoist has joined #commonlisp
zxcvz has joined #commonlisp
avocadoist has quit [Read error: Connection reset by peer]
avocadoist has joined #commonlisp
poselyqualityles has quit [Ping timeout: 268 seconds]
zxcvz has quit [Quit: zxcvz]
avocadoist has quit [Ping timeout: 240 seconds]
nij- has quit [Ping timeout: 256 seconds]
pestctrl has quit [Remote host closed the connection]
rgherdt_ has joined #commonlisp
rgherdt has quit [Ping timeout: 264 seconds]
tyson2 has joined #commonlisp
rgherdt_ has quit [Remote host closed the connection]
rgherdt has joined #commonlisp
pestctrl has joined #commonlisp
dcb has joined #commonlisp
Gleefre has joined #commonlisp
euandreh1 has joined #commonlisp
euandreh has quit [Ping timeout: 240 seconds]
euandreh1 is now known as euandreh
nij- has joined #commonlisp
_dcb_ has joined #commonlisp
dcb has quit [Remote host closed the connection]
<nij->
Is there any CL implementation that provides a function that turns any piece of CL code into its first stage IR, which I can inspect in a lisp repl?
azimut has joined #commonlisp
_dcb_ is now known as dcb
<beach>
What is it that you are trying to do?
<beach>
I mean, probably every implementation has such a function somewhere, but it may not be documented for direct use like that.
<nij->
I want to pick a CL implementation and study its compiler. However, I'm not good enough to just read the code. It'd be helpful if I can inspect the IR directly.
<beach>
Depending on the Common Lisp implementation, the result might not be terribly helpful. For example, in SICL, the first IR is an AST which is a fairly direct translation of the source code into a graph of nodes where each node indicates what the source code is, like a function call, a block, etc.
<nij->
Or maybe I should just "grow up" and start to approach codes directly without over-relying on a repl.
<jackdaniel>
nij-: studying compilers is a very fun activity, but expecting to be spoon-fed with everything may be a bit much of an expectation
<pjb>
nij-: but they provide (disassemble (function foo)) so…
<nij->
jackdaniel What would you recommend? I'm also ready to be told whatever "level-up" i need to do.
<nij->
pjb Not to the first-stage IR?
<pjb>
nij-: and if you're looking at the sources of their compilers, you may find if such a function exist (not all compilers have an first stage IR!)
<nij->
beach - sad to say but I never got SICL working.. otherwise that would be my best impl to study
<jackdaniel>
nij-: you may take cleavir (compiler proposed by beach and developed further by Bike and clasp team) and study it by first examining documentation and code
<yitzi>
nij-: you may need to put a colon after the person's nick in order them to get a notification on their IRC client.
<beach>
nij-: You couldn't get it to work because it is not finished. But if you hang out in #sicl, you can ask questions about what we do in SICL and Clasp.
<nij->
jackdaniel That sounds like a good idea. Although SICL is not working for me yet, CLEAVIR should..
<jackdaniel>
or i.e you may take a look at src/cmp/ in ecl and start from there; my point is that studying is very much about exploring things
<beach>
nij-: Bike is working on something that might be more or less directly usable for what you want.
<beach>
nij-: But seriously, I think you would be better off asking questions. If you just study the result, you will not understand why it looks the way it does.
<nij->
Ah I remember.. cleavir's test cases were obsolete and are waiting to be rewritten. That's why I stopped. - However, I can also just read without relying on test cases.
<beach>
nij-: There are two Cleavir versions. The one Bike is working on is much more complete.
<nij->
I try not to bomb you or other people here with primitive questions.. so I was hoping if I can explore the IR via the repl myself I can be more or less independent.
<beach>
Oh, and also, I think you won't be able to explore it via the REPL.
<nij->
beach: last time I asked, iirc, Bike's version of Cleavir still lacks tests.
<beach>
nij-: We wrote special viewer programs in order to decipher the different intermediate representations.
<nij->
The viewer programs work on linux, but I couldn't get it to work on macos :/
jonatack has joined #commonlisp
<beach>
What I am trying to say is that the intermediate representations are often directed graphs, and it is hard to get an idea of what they mean using only the REPL.
<nij->
I see.
IAmRasputin has quit [Quit: WeeChat 3.8]
<beach>
Did you already study the literature on compilers?
<nij->
Lets go to clschool if you are interested.
<beach>
Fine with me.
azimut has quit [Ping timeout: 240 seconds]
Gleefre has quit [Remote host closed the connection]
Gleefre has joined #commonlisp
pranavats has left #commonlisp [Disconnected: Hibernating too long]
mgl has joined #commonlisp
pranavats has joined #commonlisp
Oladon has joined #commonlisp
Gleefre has quit [Remote host closed the connection]
nij- has quit [Ping timeout: 240 seconds]
soundmodel has joined #commonlisp
shka has quit [Read error: Connection reset by peer]
azimut has joined #commonlisp
shka has joined #commonlisp
NotThatRPG has joined #commonlisp
lucasta has joined #commonlisp
tyson2 has quit [Remote host closed the connection]
nij- has joined #commonlisp
igemnace has joined #commonlisp
Gleefre has joined #commonlisp
Gleefre has quit [Remote host closed the connection]
nij- has quit [Ping timeout: 246 seconds]
Gleefre has joined #commonlisp
McParen has joined #commonlisp
Oladon has quit [Quit: Leaving.]
soundmodel has quit [Ping timeout: 245 seconds]
euandreh has quit [Ping timeout: 264 seconds]
lucasta has quit [Remote host closed the connection]
tyson2 has joined #commonlisp
pestctrl has quit [Remote host closed the connection]
attila_lendvai has joined #commonlisp
Catie` has joined #commonlisp
Catie` has quit [Read error: Connection reset by peer]
pestctrl has quit [Remote host closed the connection]
tyson2 has quit [Ping timeout: 246 seconds]
tibfulv has quit [Remote host closed the connection]
tibfulv has joined #commonlisp
McParen has left #commonlisp [#commonlisp]
Catie has joined #commonlisp
cage has quit [Quit: rcirc on GNU Emacs 28.2]
Catie` has quit [Ping timeout: 240 seconds]
euandreh has joined #commonlisp
Catie` has joined #commonlisp
johnjaye has quit [Quit: WeeChat 4.0.0-dev]
Catie has quit [Ping timeout: 246 seconds]
dino_tutter has quit [Ping timeout: 240 seconds]
johnjaye has joined #commonlisp
anticomputer has quit [Ping timeout: 240 seconds]
anticomputer has joined #commonlisp
dino_tutter has joined #commonlisp
tyson2 has joined #commonlisp
czy has quit [Remote host closed the connection]
rogersm has joined #commonlisp
czy has joined #commonlisp
<Bike>
not sure what tests have to do with learning how something works.
<Bike>
for cleavir i wrote a whole example system with documentation to show how it works, and even if you can't get the visual disasssembler working there's a textual one.
waleee has joined #commonlisp
attila_lendvai has quit [Ping timeout: 240 seconds]