libera/#commonlisp - IRC Chatlog
Search
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...
16:08:03
pjb
beach: some unix applications have been written like that. Even GUI applications (thanks to X11 subwindows model).
16:09:24
beach
pjb: I believe you. But the fact that the applications I cited are not written like that, suggests that it is not a great way to create large interactive applications.
16:10:39
pjb
I'm not sure. It may be a great way, but for political reasons corporations don't want to do it. For example, Apple started once upon a time into this direction (document oriented architecture), but quickly backtracked, for no good technical reasons AFAICS.
16:11:24
shka
oh, apple will not do that because of how would you profit on selling parts of the applications in the iStore?
16:12:58
pjb
Also, it's funny that since NeXT computer bought back Apple, they've forced on them a component architecture, even if it's only at the Object/Class level instead of at a system level.
16:13:02
beach
pjb: OK, let me put it this way then. I wouldn't dream of writing an applications such as Firefox, KiCad, MuseScore, etc. by splitting it into small modules that would communicate using pipes of byte streams.
16:14:59
beach
This entire time, I was talking about the in infeasibility of the Unix philosophy of writing an application as collaborating individual programs piped together with byte streams.
16:16:43
shka
i would argue that the last part of this statement describes the implementation of the unix philosophy, but not itself
16:17:03
jcowan
I've been thinking about how to implement funcallable instances where there are none from ordinary functions-with-state. It can be done, except that because functions are opaque you cannot write a predicate function to detect them.
16:19:25
jcowan
beach: I think the reason why you don't see such systems much is educational. Many people came to Unix for its advantages, but their habits were already formed: if you want to do something, write a monolithic app; if you want to do something else, write another monolithic app or change the one you have to add more options.
16:21:00
pjb
There are unix "applications" that are written as a set of commands invoked directly from the shell, used as a REPL for the application. For example, MH.
16:21:01
jcowan
In addition, threads were implemented around mutexes rather than message-passing; if it had been otherwise, the difference between threads and processes would be performance.
16:29:20
aeth
jcowan: people don't use Unix because of the way of Unix, they use it because it's the first class platform for most new programming languages (perhaps all except the Microsoft ones)... and eventually they trickle over to get 95% support on Windows
16:29:55
aeth
(OK, maybe game-oriented programming languages get first-class Windows support quickly, too, but there are few niches that are overwhelmingly Windows like that)
16:30:35
jcowan
EVen those who haven't worked on Windows, becuse monolithic code is the prevailing orthodoxy.
16:31:31
aeth
Just most wind up being scripting languages for the web and not very different from each other.
16:32:04
jcowan
I don't agree: there is nothing about Java or C++ or any other language that requires monolithic apps. It's a much higher-level concern.
16:35:08
jcowan
I wrote a substantial Web 1.0 (no JavaScript) application entirely in perl and bash (and one C program that was a performance bottleneck); there were about 100 programs. It was lightning fast, though precomputation and caching helped a lot with that.
16:36:38
aeth
well, Perl's explicit language model was to be a better sh/awk/etc. so it's not surprising that perl-and-bash go well together
16:40:38
jcowan
That included all the back-end database maintenance, because the database was the file system. Very fast, very robust, no server required.
16:44:32
pjb
Indeed, the killer feature of unix, is the creation of new executable. cc -o my-program source.c && ./my-program ; on any other systems, it's way more complicated to go from successful compilation to launching your program. You have to manage libraries, install (and have the access rights to do so) the program, write JCL or whatever.
16:45:12
pjb
Eg. on iOS you must go thru the AppStore, codesign, write up descriptive forms, wait for Apple's approval, etc.
16:58:59
remexre
am I failing at reading, or does clhs 11.1.2.1.2 not actually state (intern "FOO" :CL) should be an error?
17:04:50
Bike
11.1.2.1 could be read to mean that adding or removing _external_ symbols is not allowed, though
17:15:49
jcowan
The title of that section is actually misleading: it's constraints on the external symbols of the cl package.
17:16:21
jcowan
However, "It also follows that conforming programs can use external symbols of the COMMON-LISP package as the names of local lexical variables with confidence that those names have not been proclaimed special by the implementation unless those symbols are names of standardized global variables" could not hold if you were able to intern arbtirary external names into the package.
17:17:59
jcowan
I really don't think that the spec authors expected the cl package to be anything but immutable.
17:18:15
aeth
If you package-lock CL like in SBCL then you have to have (intern "FOO" :CL) fail or else you can add to it something that you can't then remove.
17:19:08
aeth
polygon-op: no, CL package external symbols are undefined behavior if you treat them as if they are not locked
17:19:18
aeth
Which means that portably, you have to treat it like it's locked because it will be in some implementations
17:20:06
aeth
So for you, the Lisp program/library author, you have to treat it as if it's locked. Implementations do not, though.
17:20:31
jcowan
As I said, that is all about what you can do with external cl: symbols. There is nothing about creating symbols there.
17:22:30
jcowan
It's a subtle point, the fact that immutable containers and immutable objects in the containers are independent.
17:23:18
aeth
Yes, but for practical purposes, you especially want to lock the internals because otherwise a lot of programs will be written (in-package #:cl) because it's easier than using CL
17:30:39
jcowan
(at least in the old days; Fortran is a pretty powerful array-processing language today, and even has a non-backward-compatible subset called F.)
17:38:04
aeth
I think it limits itself to the externals of COMMON-LISP because it sees the internals of COMMON-LISP as an implementation detail (e.g. do you implement it inside of COMMON-LISP or do you implement it elsewhere and import it into COMMON-LISP before reexporting or both?)
17:38:37
aeth
And messing with implementation internals is, of course, implementation-specific rather than standard.
17:40:10
aeth
It gives you just enough to know that users aren't expected to be able to redefine #'+ into #'*, though, which lets you make assumptions as a macro author.
17:41:25
aeth
Of course, the user might be able to, but now you can get mad at the user for abusing non-portable UB