freenode/#lisp - IRC Chatlog
Search
6:06:42
beach
ober: There is a part of CLOS that is in the Common Lisp standard, but the MOP has many more features than that, some of which are even contradicting the standard.
6:29:08
aeth
loke: I think it's something small like something that's normally a function, but with MOP is a generic function instead or something. But apparently that isn't against the standard, so I have to be misremembering the details
6:56:53
beach
It may have been small stuff like one saying "the consequences are undefined" and the other one that "an error is signaled".
7:11:20
no-defun-allowed
I don't think whoever came up with the spam bot programmed it to explain itself, sadly.
7:12:04
beach
I am not looking for an explanation. I am looking for the absence of one, so that I don't have to follow the link.
7:13:31
White_Flame
LdBeth: one interesting use of &aux that I've found is computing derived struct slot values in the declared BOA constructor without needing a function body
7:17:31
loke
Wow. I didn't know that was possible. And even though I now know about it, I don't think I'll ever use it.
7:19:27
White_Flame
ACTION likes shortcuts when possible and fits the intent. Plus, with Lisp it's pretty easy to unroll into "full form" if it gets past the scope of the shortcut
10:51:24
jmercouris
Ok, so yesterday we established that we can't do FFI to C++ because the ABI is not standard in C++ world
11:43:06
no-defun-allowed
Standardise the C++ ABI? That would be half-polite of the – well, sure. No good if you want to use Qt though.
11:45:03
beach
But I will be quiet now because I am not adding anything new that I haven't already said.
11:48:53
no-defun-allowed
I agree life is much simpler if you are able to avoid FFI completely or avoid it as much as possible, or if you grow vegetables; but there may be reasons one wants to use Qt.
11:51:34
no-defun-allowed
My favourite reason is to use the Qt WebEngine to load documents off a CL server, and implement the UI in HTML/CSS/JavaScript. Then use your favourite C->JavaScript transpiler to run Qt in the browser, and repeat until you get bored.
11:55:24
no-defun-allowed
But seriously, it may be less effort per individual to bite the bullet and work with Qt than to test/port/develop/&c a CL toolkit, even though all the time taken to accomodate for foreign code would probably add up to more than enough required to make that toolkit work.
13:18:29
beach
I am convinced we represent an instance of the prisoner's dilemma. The optimal solution is to collaborate to create Common Lisp solutions to our collective software needs, but individually, it is better to take the FFI route.
13:18:31
beach
As a result, everybody pays the price of increased development and maintenance burden. Except those who can and do choose to work on something that can be done entirely in Common Lisp.
13:22:09
beach
FFI solutions require a different kind of maintenance, namely catching up with moving targets, like Qt versions, LLVM versions, Gnome versions.
13:28:44
Xach
I wrote pure lisp stuff for gifs and pngs because I was frightened by the thought of foreign code crashing my long-running server.
13:31:09
_death
I didn't write OpenCV in pure lisp because it would require tens of thousands of man hours or more..
13:33:11
beach
Anyway, having identified the reason for the state of things, I now understand much better what is going on, and I know that it would usually be futile to try to influence someone's choice.
13:33:45
_death
beach: but you could also flip it, so that the utilitarian solution is to use the language where most effort has already gone to, and the choosing Lisp is the egoistic individual choice
13:36:06
beach
That might have been true if the "utilitarian solution" were effortless or nearly so. The many questions and problems related to FFI solutions that are discussed here suggest otherwise.
13:41:26
_death
there is reason, but it is an egoistic reason.. I like CL better than C++, so I don't mind putting effort into making the rest of the world work with CL.. only a small group of people may benefit from this choice
13:41:52
beach
_death: You don't need an excuse to choose the FFI solution ("tens of thousands of man hours or more"). Like I said, it is perfectly clear to me now why this solution is optimal to the individual.
13:45:40
beach
_death: I think that is a very good idea, i.e. create a Common Lisp "wrapper" for an existing foreign library. However, what I usually observe is a badly documented wrapper library that requires the user to understand both the foreign library, the foreign language it is written in, *and* the undocumented code of the wrapper.
13:45:41
beach
I am not saying this is the case with yours of course. I haven't looked at it at all.
13:47:31
_death
beach: I definitely agree with this observation.. I think it's difficult to design good interfaces, and the Lisp standard is a high one.. it's much easier to ape the foreign library's existing interface.. in the past I did that, but also did the harder work at times
13:49:34
_death
beach: it also has to do with means and ends.. if utilization of this library is just a means to an urgent end, then it's likely the initial solution would involve less thought about the interface
13:50:22
beach
Yes, but then it is not really usable by a wide audience. And we are back to the prisoner's dilemma.
15:53:23
Shinmera
Speaking of UI, though, here's another brief demo for Alloy I put together today https://youtu.be/oLRBZrdzJS0
16:07:38
Kabriel
Shinmera: that looks like plotting. Excuse my ignorance, but is this part of McCLIM or based on it, or something else?