libera/#commonlisp - IRC Chatlog
Search
3:34:41
subst
I've looked at this channel's logs. Most of the activity happens overnight in my time zone.
3:35:50
subst
Seems to be true for Lisp in general. There's a European Lisp Symposium but not an American one.
3:37:04
beach
But there are people from all over, so if you have any questions, there is usually someone to ask.
3:38:52
beach
There used to be an International Lisp Conference (ILC) organized by the ALU (Association of Lisp Users), but I think the ALU has difficulties finding people who are interested.
3:39:21
beach
ELS is currently mainly driven by Didier Verna, but who knows what will happen when he gets tired of it.
3:40:03
subst
It seems like there might not be a next generation to maintain all the Lisp implementations out there.
3:41:14
beach
SBCL is well maintained. ECL is taken care of by jackdaniel. CCL is still worked on by rme, I think. And I have seen bhaible around here, so maybe CLISP is maintaned too.
3:42:05
beach
Don't despair! We are working on a new fresh implementation that will attract new people to work on. It already has in fact.
3:44:38
beach
Here I thought I was the first one to write a Common Lisp implementation using the full language. Oh well. Congratulations!
3:45:42
subst
It's extremely slow and the interpreter is a mess. I tried using C++ exceptions to implement nonlocal jumps, and C++ RAII to implement UNWIND-PROTECT. The two don't go together.
3:47:09
moon-child
beach: sacla is another such, albeit nascent and abandoned: https://minejima.jp/lisp/sacla/index-en.html
3:47:30
subst
It wouldn't be so much of a problem for my implementation if I didn't also use destructors. The problem is that C++ calls std::terminate if a nonlocal jump is performed from Lisp code called from a destructor.
3:47:48
beach
moon-child: Yes, I am aware of Sacla, But I don't think there was even an attempt to bootstrap it.
3:49:25
beach
subst: I am curious, in what way did you find your implementation similar to SICL, if yours is written in C++?
3:52:31
subst
My problem is, if you invoke a restart, and it causes an UNWIND-PROTECT to run, and the UNWIND-PROTECT invokes another restart, that causes C++ to call std::terminate().
3:54:12
beach
You may want to ask the Clasp people about things like that. They know everything about implementing Common Lisp in C++.
3:56:38
beach
moon-child: It is easy to use the full language to implement Common Lisp if you don't care about how to bootstrap it. :)
4:04:58
subst
I tried using it as a reference for the MOP, while I implemented a CLOS interface to Objective-C classes.
4:08:20
beach
I don't particularly like the way chapters 5 and 6 are ogranized, so I wrote this site: http://metamodular.com/CLOS-MOP/clos-mop.html
4:09:57
beach
There was an already existing HTML version of those chapters, but the authors didn't respect the desires of the authors of the AMOP book and make the HTML markup restricted by copyright and such. Plus, the HTML wasn't very good.
4:12:00
subst
I had to look up another source to figure out how to get STANDARD-DIRECT-SLOT-DEFINITIONS to work. AMOP forgot to mention that you need to implement DIRECT-SLOT-DEFINITION-CLASS and EFFECTIVE-SLOT-DEFINITION-CLASS for your metaclass.
4:15:38
subst
You can extend CLOS slots to have extra slot-options. The standard ones are things like :INITARG, :ACCESSOR, etc. I needed extra options that were specific to Objective-C. AMOP describes how to create your own slots, but doesn't say (as far as I recall, anyway) how to get your metaclass to use these new slots.
4:23:38
subst
Oh well. I was about to go to bed. No need to go into the weeds about a library I'll never have time to finish.
4:33:42
subst
I wonder what you'd think the best way to do this is: My Obj-C wrapper library implicitly creates an Objective-C class for every class defined with the OBJECTIVE-C-CLASS metaclass. Every slot in an OBJECTIVE-C-CLASS has both a CLOS slot and an Objective-C Ivar (which is in most cases a CFFI pointer).
4:33:51
subst
Sometimes you want to assign an OBJECTIVE-C-CLASS object to a slot in another OBJECTIVE-C-CLASS object. But you can't do this fully, because you can't assign a CLOS object to a foreign pointer.
4:33:54
subst
So my metaclass looks inside the object and pulls out the Objective-C foreign pointer that backs it, and assigns that to the Objective-C Ivar. Then it assigns the CLOS object to the CLOS slot.
4:36:03
subst
The problem comes when you want to look at the CLOS object after that. If you've passed the containing object to an Objective-C function, it might have replaced the object in the Ivar with a different one. So when you retrieve the slot, my metaclass has to create a new CLOS object, wrapping the same Objective-C object as what you originally put in.
4:36:19
beach
Wow, that sounds like a messy problem. I know very little about Objective C and I stay away from FFI to avoid messy problems.
4:37:21
subst
It is very messy, and probably the reason why I've let this project sit for years now.
4:38:44
beach
The Clasp people might have some clues. They made C++ classes managed by the Common Lisp GC. Maybe you could do something similar.
4:40:08
moon-child
it's reference-counted though. So I guess on the cl side you could increment the reference count once, and then when freeing the object decrement it again
4:40:25
moon-child
basically treating the whole cl heap as a single referent from objc's perspective
4:42:16
subst
The messiness comes from having this surrogate CLOS object that represents, but isn't identical to, an ObjC object. The CLOS objects end up being like ORM objects in that you can have two objects with distinct addresses (ie, not EQ) that represent the same object in the backing store (in this case ObjC).
10:45:17
jmercouris
and of course: https://stackoverflow.com/questions/52788032/getting-common-lisp-process-id-on-linux
10:58:02
dim
portable in terms of CL implementations, but is it portable in terms of OS? /proc is linux only, pidof might exist in some other unixes such as FreeBSD or macOS but I'm not sure if they are part of the base OS, etc
13:46:54
lisp123
if I pass a function as a parameter to a function (e.g. (defun my-function (my-cool-function)... can I call it simply as (my-cool-function ...) or do I need to do some sort of funcall?
13:48:56
lisp123
for some reason I kept thinkging I coudl just do (#'my-cool-function ...) but hopefully I remember this time
13:49:24
lisp123
(i now understand that #' prevents evaluation... so what I wrote is nonsensical...just the bad thing got stuck in my mind)
13:53:24
beach
lisp123: #' is a reader macro that turns #'BLA into (FUNCTION BLA) and FUNCTION is a special operator that, when given a function name, returns the function with that name in the current lexical environment.
13:54:06
beach
So saying that #' prevents evaluation is not quite the right terminology. I kind of makes you think it works like QUOTE.
13:54:54
lisp123
yeah I agree, its a bad habit, I shouldn't do that. Important to remember that it returns the function object
13:55:33
beach
To see that it's just a reader macro, try something like (let (#'234) (+ function 10))
13:55:45
lisp123
hopefully I will remember soon all of this, I'm starting my journey away from simplistic lisp functions to abstracting all the structure away and passing in functions :) Feels cool :)
13:57:29
lisp123
write a generic function which contains all the logic at the most abstract level possible, then pass in both functions & variables to make it come to life
13:59:30
lisp123
There's a quote in On Lisp: it’s easier to abstract out the bones of a function when you can pass the flesh back as a functional argument.
14:00:43
beach
Be a bit careful though. Graham doesn't seem to like CLOS, and often another way of accomplishing such abstraction is exactly by using CLOS generic functions.
14:01:13
lisp123
beach: actually it was on my list to ask - is there any particular reason why he doesn't like CLOS?
14:05:30
beach
That page sounds like his on description of someone looking upward toward BLOOP, and not understanding it.
14:06:26
_death
he's saying that he never used CLOS in that page :).. although he obviously knows it on some level
14:07:26
beach
Also, describing CLOS as "object orientation" makes it possible to think that CLOS is just another "object-oriented language" like the others.
14:09:49
beach
"I personally have never needed object-oriented abstractions." sounds like stuff we hear all the time, like "I have never needed macros", or "I have never needed first-class packages"
14:11:07
yitzi
I think that his items 2 & 3 make a lot of good points, but should actually be prefaced with "In languages with bad object oriented facilities..." or something like that.
14:11:12
_death
well, Lisp supports many paradigms, and some may not feel the need to use a particular one to solve their problems
14:12:22
yitzi
I find myself falling into those two behaviors when programing in something like Python or Java, but not CL.
14:14:06
beach
lisp123: Either way, you can safely ignore Paul Graham's opinion when you decide whether to use generic functions or standard classes..
14:14:15
polygon-op
that said imo it is easy to unnecessarily complicate the program using clos, but that applies to any powerful enough tool
14:15:34
lisp123
beach: Yeah I like CLOS alot :) It helps reduce the complexity of my programs because I'm not smart enough to keep wandering down the call stack of too many functions and this way I can have something "concrete" that I can isolate to itself (like an object)
14:15:41
beach
polygon-op: Yes, but it seems like overkill to avoid those tools entirely just to avoid that possibility.