libera/#commonlisp - IRC Chatlog
Search
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.
14:17:31
polygon-op
lisp123: in clos the generic function is the most prominent object, not the instance this function is specialized on
14:18:34
_death
lisp123: so I don't think PG dislikes CLOS.. in some other place he calls it "elephantine", I guess.. but I think his reaction is more a backlash against OO craze in the 90s than CLOS in particular
14:18:39
polygon-op
and your argument could be turned around: having a reasonably complex class hierarchy and a protocol with numerous auxiliary methods it may become a spaghetti
14:19:30
lisp123
_death: When I read that link, it seemed to be exclusive of CLOS and more general towards other OO languages, particularly in their form in the 90s
14:20:49
lisp123
polygon-op: yep, hence I'm always writing and re-writing my code - and trying to get a better feel of when to CLOS, when not to etc. Its enjoyable to be able to think about these concepts - in other languages, I didn't really think too much at this level, was just churning out code (probably due to the amount of boilerplate means one misses the forest for the trees)
15:20:59
subst
I've got a CLOS implementation question: How does one make funcallable instances without building support for them directly into the Lisp compiler/interpreter?
15:27:01
Bike
like you might define funcall to check the tag of the object to make sure that it's a function, and then if it is, call the code pointed to by a field at such and offset in the function
15:27:19
Bike
then a funcallable instance is an object that has a function tag and has code at that field, plus whatever other data for slots etc.
15:28:13
Bike
it means the evaluator and compiler don't need to know anything special about funcallable instances
15:29:17
subst
But if you have a compiler or interpreter that aren't designed with funcallable instances in mind, you can't add them later by writing Lisp code.
15:31:05
subst
I guess the workaround would involve special logic in SLOT-VALUE to treat closures like instances?
15:32:20
beach
It's a good question, because I think that's actually the only modification to an implementation that was required for a pre-ANSI Common Lisp implementation to support CLOS.
15:34:17
subst
I was looking at Symbolics Genera a long time ago and noticed that its CLOS didn't support funcallable instances. And FLAVORS was built entirely on special behavior in FUNCALL/APPLY. If Genera had funcallable instances, it'd be possible to create CLOS objects that can simultaneously be used as FLAVORS objects. But it doesn't, so you can't.
15:36:46
beach
Why would you want to do that now that all Common Lisp implementations have it? Specifically for Genera?
15:38:47
subst
For Genera, yes. If I understood it better I could properly add the runtime support, but I don't plan on becoming an expert in the internals of a dead operating system.
15:46:21
subst
But I don't see how the driver problem can be overcome. That alone seems like it should chain us to C (or worse yet, Rust) until hardware companies say otherwise, which means basically forever.
15:49:27
beach
The important part of an operating system is how applications interact with the system and with one another. Even if some hardware companies forces drivers to be in their proprietary form, a great operating system could be created.
15:55:04
shka
you could run linux kernel in the user space, as an application and use it to control the hardware
15:57:08
shka
and besides, realistically running unsafe code would require something like this anyway
15:58:51
beach
My point is that the most important part is not that everything be written in Lisp from the bottom up. The important part is the programming model.
15:59:47
beach
Of course, the more code is written in Lisp, the more likely the total system is to be safe, so it would be good to have a sort of migration path.
16:02:59
beach
Except that it failed miserably in Unix. I mean do you see things like Firefox, KiCad, MuseScore being written as small applications piped together with a shell script?
16:03:42
beach
It didn't even work well at the time with batch applications. The entire `troff' pipe was a disaster.
16:05:05
beach
But it can work with the more sophisticated interaction that is allowed between Lisp functions, compared to byte streams.
16:05:12
shka
if you could define anything you want and share it across the whole system a full fledged lisp object...