<Josh_2>
is there an IDE other than Vim/emacs that supports fully interactive CL development?
<Josh_2>
My irl buddy wants to try CL however he has cerebral palsy so he cannot type properly with one hand, so no emacs/vim for him
<moon-child>
I think emacs may be doable, if you set it up so that you tap modifiers instead of holding them?
<Josh_2>
hmm didn't know you could do that
<moon-child>
I don't know if emacs natively supports it, but I'm sure you can hack it in
<moon-child>
I have a little script that does something similar for xcompose
<cjb>
if you do setup emacs, maybe don't hide the menubar. if they are able to use a mouse, the menubar is very handy if using the keyboard is a problem.
<moon-child>
I think vim is also probably feasible too, if you move keys around. I was able to use it reasonably well one-handed when I broke my arm
tyson2 has quit [Remote host closed the connection]
yitzi has quit [Quit: Leaving]
CrashTestDummy2 has joined #commonlisp
CrashTestDummy3 has quit [Ping timeout: 252 seconds]
prxq_ has joined #commonlisp
prxq has quit [Ping timeout: 252 seconds]
makomo has quit [Ping timeout: 246 seconds]
igemnace has quit [Ping timeout: 240 seconds]
Bike has quit [Quit: Lost terminal]
igemnace has joined #commonlisp
srhm has quit [Ping timeout: 240 seconds]
taiju has quit [Remote host closed the connection]
taiju has joined #commonlisp
waleee has quit [Ping timeout: 252 seconds]
<beach>
Good morning everyone!
zacts has joined #commonlisp
CrashTestDummy3 has joined #commonlisp
<subst>
Good morning, beach. It's late at night where I'm sitting.
<beach>
subst: Are you new here? I don't recognize your nick.
CrashTestDummy2 has quit [Ping timeout: 246 seconds]
<subst>
Yes, I'm new.
<beach>
Welcome! What brings you to #commonlisp?
<subst>
I heard this was where the Lisp community went after /r/Lisp all but died.
<subst>
It seems dead here, too.
<beach>
Not dead at all.
<beach>
But the US of Asians are mainly asleep and the Europeans are not awake yet.
<subst>
I've looked at this channel's logs. Most of the activity happens overnight in my time zone.
<subst>
During the day in the US, it's practically silent in here.
<beach>
I think there are many more Europeans here than US of Asians.
<subst>
Seems to be true for Lisp in general. There's a European Lisp Symposium but not an American one.
<beach>
True.
<beach>
But there are people from all over, so if you have any questions, there is usually someone to ask.
taiju has quit [Ping timeout: 252 seconds]
<subst>
I haven't had a Lisp question in a long time.
<beach>
Fair enough.
zacts has quit [Ping timeout: 246 seconds]
<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.
<beach>
ELS is currently mainly driven by Didier Verna, but who knows what will happen when he gets tired of it.
<subst>
It seems like there might not be a next generation to maintain all the Lisp implementations out there.
<beach>
I think they are maintained.
<subst>
For now. But I imagine they'll eventually run into the same problem as the ELS.
<subst>
The people currently maintaining them will retire or die, and then what?
<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.
<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.
<subst>
SICL?
<beach>
Yes.
<mfiano>
BOCL :)
<beach>
Heh.
<subst>
Looks similar to my own amateur Lisp implementation.
<beach>
Interesting!
<beach>
Here I thought I was the first one to write a Common Lisp implementation using the full language. Oh well. Congratulations!
taiju has joined #commonlisp
<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.
<beach>
Oh, it's written in C++? Then they have nothing in common.
<beach>
Clasp had a problem using C++ exceptions for non-local control transfer.
<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.
<moon-child>
(cl implementation in full cl, that is)
<beach>
moon-child: Yes, I am aware of Sacla, But I don't think there was even an attempt to bootstrap it.
<beach>
subst: I am curious, in what way did you find your implementation similar to SICL, if yours is written in C++?
<subst>
Not similar to SICL; similar to BOCL.
<beach>
Oh, he!
<beach>
Now I understand.
<beach>
Well, the idea of BOCL is to not care about performance at all.
<beach>
But maybe your problems with C++ exceptions is not just performance.
CrashTestDummy3 has quit [Read error: Connection reset by peer]
<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().
<subst>
Often times, the second restart is invoked manually by me in the debugger.
<beach>
You may want to ask the Clasp people about things like that. They know everything about implementing Common Lisp in C++.
char has joined #commonlisp
<beach>
Bike left for the day, though. drmeister is still here, but usually very busy.
<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. :)
zacts has joined #commonlisp
<beach>
CLOS is particularly tricky.
<subst>
It's supposed to be possible to implement CLOS entirely in Lisp.
<beach>
It is. I did it.
<subst>
What's the tricky part?
<beach>
PCL is also implemented in Common Lisp, but they cheat a lot as the AMOP book shows.
<beach>
That it is all metacircular.
<beach>
Also, you have to do some special stuff to get performance out of generic dispatch.
<subst>
So CLOS isn't just implemented in Lisp, it's implemented with CLOS?
<beach>
Oh yes.
<beach>
CLOS is a CLOS program.
<beach>
I recommend the AMOP book.
<subst>
I have it.
<beach>
Ah, OK.
CrashTestDummy has joined #commonlisp
<subst>
I tried using it as a reference for the MOP, while I implemented a CLOS interface to Objective-C classes.
<beach>
Also, the links make it much easier to use for a person implementing the MOP.
<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.
<mfiano>
Hex's was an eyesore
<beach>
That's yet another one. He wrote that one after I did mine.
Josh_2 has quit [Quit: ERC (IRC client for Emacs 27.1)]
<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.
CrashTestDummy has quit [Ping timeout: 252 seconds]
<subst>
I mean STANDARD-DIRECT-SLOT-DEFINITION subclasses.
<beach>
Doesn't ring a bell.
char has quit [Remote host closed the connection]
<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.
<beach>
I see, yes.
<beach>
Though, I thought the metaclass for slot definition classes was just STANDARD-CLASS.
<beach>
Classes with red text all have STANDARD-CLASS as a metaclass.
<subst>
I'm talking about the type of slot used by a metaclass, not the metaclass of a slot.
<beach>
I'm lost. But I have just barely finished my morning coffee so it is not surprising.
<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.
<beach>
OK, well, I hope there is more opportunity to talk Common Lisp implementation stuff.
selwyn has joined #commonlisp
Oladon has quit [Quit: Leaving.]
<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).
bpanthi977 has joined #commonlisp
<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.
<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.
<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.
<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.
<subst>
It is very messy, and probably the reason why I've let this project sit for years now.
<beach>
Makes sense.
<subst>
I was hoping to gain the ability to write COCOA programs in CL.
Inline has quit [Quit: Leaving]
<beach>
The Clasp people might have some clues. They made C++ classes managed by the Common Lisp GC. Maybe you could do something similar.
<moon-child>
objc has its own gc, which complicates things
<beach>
Oh, I had no idea! I should keep quiet.
<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
<moon-child>
basically treating the whole cl heap as a single referent from objc's perspective
<subst>
My code might already do that.
<beach>
Interesting idea.
<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).
bpanthi978 has joined #commonlisp
bpanthi977 has quit [Ping timeout: 252 seconds]
bpanthi978 is now known as bpanthi977
zacts has quit [Quit: zacts]
pjb has joined #commonlisp
peterhil has quit [Ping timeout: 265 seconds]
frgo has quit [Read error: Connection reset by peer]
frgo has joined #commonlisp
peterhil has joined #commonlisp
cracauer has quit [Remote host closed the connection]
cracauer has joined #commonlisp
amb007 has quit [Ping timeout: 246 seconds]
Cymew has joined #commonlisp
amb007 has joined #commonlisp
kakuhen has joined #commonlisp
shka has joined #commonlisp
dsk has joined #commonlisp
amb007 has quit [Ping timeout: 240 seconds]
amb007 has joined #commonlisp
karlosz_ has joined #commonlisp
karlosz has quit [Ping timeout: 272 seconds]
karlosz_ is now known as karlosz
amb007 has quit [Read error: Connection reset by peer]
amb007 has joined #commonlisp
leo_song_ has quit [Remote host closed the connection]
leo_song has joined #commonlisp
wheelsucker has quit [Remote host closed the connection]
wheelsucker has joined #commonlisp
treflip has joined #commonlisp
madnificent has quit [Ping timeout: 250 seconds]
kakuhen has quit [Ping timeout: 252 seconds]
madnificent has joined #commonlisp
amb007 has quit [Read error: Connection reset by peer]
amb007 has joined #commonlisp
amb007 has quit [Read error: Connection reset by peer]
amb007 has joined #commonlisp
amb007 has quit [Read error: Connection reset by peer]
amb007 has joined #commonlisp
hendursa1 has quit [Ping timeout: 244 seconds]
easye has quit [Remote host closed the connection]
easye has joined #commonlisp
pve has joined #commonlisp
makomo has joined #commonlisp
peterhil has quit [Ping timeout: 246 seconds]
Lord_of_Life_ has joined #commonlisp
Lord_of_Life has quit [Ping timeout: 246 seconds]
Lord_of_Life_ is now known as Lord_of_Life
kakuhen has joined #commonlisp
cjb has quit [Quit: rcirc on GNU Emacs 28.0.50]
Lycurgus has joined #commonlisp
attila_lendvai has joined #commonlisp
Lycurgus has quit [Quit: Exeunt]
scymtym has quit [Ping timeout: 258 seconds]
mankaev has joined #commonlisp
mankaev has quit [Client Quit]
rogersm has joined #commonlisp
kevingal has joined #commonlisp
dsk has quit [Ping timeout: 252 seconds]
learning-cl has joined #commonlisp
derelict has quit [Ping timeout: 252 seconds]
amb007 has quit [Read error: Connection reset by peer]
amb007 has joined #commonlisp
amb007 has quit [Read error: Connection reset by peer]
amb007 has joined #commonlisp
amb007 has quit [Read error: Connection reset by peer]
selwyn has quit [Read error: Connection reset by peer]
amb007 has joined #commonlisp
scymtym has joined #commonlisp
frgo has quit [Remote host closed the connection]
frgo has joined #commonlisp
amb007 has quit [Read error: Connection reset by peer]
amb007 has joined #commonlisp
learning-cl has quit [Quit: Client closed]
Guest49 has joined #commonlisp
Guest49 has quit [Client Quit]
amb007 has quit [Ping timeout: 252 seconds]
amb007 has joined #commonlisp
peterhil has joined #commonlisp
tyson2 has joined #commonlisp
amb007 has quit [Read error: Connection reset by peer]
<jmercouris>
wow, I just found out about (apropos "xyz")
<jmercouris>
what an amazing thing
<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
<jmercouris>
implementations, not OS
<jmercouris>
obviously it won't work on TempleOS, for example
lisp123 has joined #commonlisp
amb007 has quit [Read error: Connection reset by peer]
andrei-n has joined #commonlisp
amb007 has joined #commonlisp
derelict has quit [Ping timeout: 246 seconds]
cracauer has quit [Remote host closed the connection]
selwyn has joined #commonlisp
andreyorst has quit [Ping timeout: 258 seconds]
CrashTestDummy3 has joined #commonlisp
CrashTestDummy2 has quit [Ping timeout: 246 seconds]
hendursa1 has joined #commonlisp
attila_lendvai has quit [Read error: Connection reset by peer]
yitzi has joined #commonlisp
attila_lendvai has joined #commonlisp
lucerne has quit [Read error: Connection reset by peer]
greyrat has quit [Read error: Connection reset by peer]
notzmv has joined #commonlisp
notzmv has quit [Remote host closed the connection]
notzmv has joined #commonlisp
andreyorst has joined #commonlisp
rogersm has quit [Quit: Leaving...]
Bike has joined #commonlisp
IAmRasputin has joined #commonlisp
notzmv has quit [Ping timeout: 246 seconds]
luna-is-here has quit [Quit: luna-is-here]
luna-is-here has joined #commonlisp
unyu has joined #commonlisp
IAmRasputin has quit [Ping timeout: 240 seconds]
unyu has left #commonlisp [#commonlisp]
<jcowan>
jmercouris: Then again, what does work on TempleOS (other than internal things)?
<edgar-rft>
As far as I have understood God does all the work on TempleOS :-)
<edgar-rft>
you only need to type some Hallelujah on the commandline...
waleee has joined #commonlisp
dsk has joined #commonlisp
yitzi has quit [Remote host closed the connection]
srhm has joined #commonlisp
yitzi has joined #commonlisp
IAmRasputin has joined #commonlisp
CrashTestDummy2 has joined #commonlisp
<lisp123>
quick qn because I'm lazy
<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?
<Bike>
you need to use funcall, yes.
<lisp123>
thanks bike
<Bike>
(funcall my-cool-function ...)
<lisp123>
much appreciated :)
<IAmRasputin>
or apply, if the last arg is a list, right?
CrashTestDummy3 has quit [Ping timeout: 268 seconds]
<beach>
Yes, or MAPCAR or any other function that takes a function as an argument.
<lisp123>
got it - thanks
<lisp123>
for some reason I kept thinkging I coudl just do (#'my-cool-function ...) but hopefully I remember this time
isekaijin has joined #commonlisp
<lisp123>
(i now understand that #' prevents evaluation... so what I wrote is nonsensical...just the bad thing got stuck in my mind)
<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.
<lisp123>
beach: yup
<beach>
So saying that #' prevents evaluation is not quite the right terminology. I kind of makes you think it works like QUOTE.
srhm has quit [Quit: Konversation terminated!]
<lisp123>
yeah I agree, its a bad habit, I shouldn't do that. Important to remember that it returns the function object
<beach>
To see that it's just a reader macro, try something like (let (#'234) (+ function 10))
<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 :)
<beach>
Uh oh!
<beach>
What does "abstracting all the structure away" mean?
<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
<lisp123>
the generic function = the structure
<beach>
If I change your terminology a bit, I think I understand what you mean.
<beach>
The problem is that "generic function" is a technical term in Common Lisp.
<lisp123>
yeah, i probably didn't word it right
<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.
<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.
<beach>
Not always, of course.
<lisp123>
beach: actually it was on my list to ask - is there any particular reason why he doesn't like CLOS?
<beach>
I think you would have to ask him.
<lisp123>
(valid) reason* - or does it seem like just a personal opinion
<beach>
People have strange opinions sometimes. Not always rational.
<lisp123>
true. I would like to ask him but he seems like a busy man
<beach>
I was going to say that his answer is not terribly important.
<beach>
That page sounds like his on description of someone looking upward toward BLOOP, and not understanding it.
srhm has joined #commonlisp
<_death>
he's saying that he never used CLOS in that page :).. although he obviously knows it on some level
Danishman has quit [Quit: Leaving]
<beach>
Also, describing CLOS as "object orientation" makes it possible to think that CLOS is just another "object-oriented language" like the others.
yitzi has quit [Remote host closed the connection]
yitzi has joined #commonlisp
tyson2 has quit [Read error: Connection reset by peer]
tyson2 has joined #commonlisp
<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"
<lisp123>
true - until you experience something, you won't have the need for it
<beach>
Sure, but there is also the word "need" in there. You don't "need" very much.
<beach>
It's a matter of what makes you the most productive.
<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.
<_death>
well, Lisp supports many paradigms, and some may not feel the need to use a particular one to solve their problems
<beach>
yitzi: Exactly.
<_death>
I guess PG likes the data driven style
<yitzi>
I find myself falling into those two behaviors when programing in something like Python or Java, but not CL.
<polygon-op>
scheme background probably played a role
<beach>
lisp123: Either way, you can safely ignore Paul Graham's opinion when you decide whether to use generic functions or standard classes..
<polygon-op>
that said imo it is easy to unnecessarily complicate the program using clos, but that applies to any powerful enough tool
<polygon-op>
(that is, generic functions and/or standard classes :)
<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)
<beach>
polygon-op: Yes, but it seems like overkill to avoid those tools entirely just to avoid that possibility.
<polygon-op>
sure
<polygon-op>
lisp123: in clos the generic function is the most prominent object, not the instance this function is specialized on
<lisp123>
Yep
<_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
<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
<polygon-op>
the argument about the call stack*
<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
<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)
<polygon-op>
it is said that a good abstraction saves thought
notzmv has joined #commonlisp
notzmv has quit [Ping timeout: 252 seconds]
waleee has quit [Ping timeout: 246 seconds]
_whitelogger has joined #commonlisp
bpanthi977 has quit [Ping timeout: 252 seconds]
srhm has quit [Ping timeout: 258 seconds]
lisp123 has quit [Remote host closed the connection]
lisp123 has joined #commonlisp
andrei-n has quit [Quit: Leaving]
lisp123 has quit [Ping timeout: 252 seconds]
srhm has joined #commonlisp
Lycurgus has joined #commonlisp
<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?
bpanthi977 has joined #commonlisp
lisp123 has joined #commonlisp
<Bike>
well, the usual way involves runtime support
<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
<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.
<Bike>
does that constitute "building support for them directly into the interpreter"?
<Bike>
it means the evaluator and compiler don't need to know anything special about funcallable instances
<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.
<beach>
They need some support from the implementation, sure.
<Bike>
i can imagine some ugly workarounds using closures, i guess
<beach>
At least if you want them to be reasonably fast.
<beach>
Yes, that workaround could possibly work.
<subst>
I guess the workaround would involve special logic in SLOT-VALUE to treat closures like instances?
<subst>
And possibly in other places too?
<beach>
Sounds right.
<Bike>
something along those lines, yeah.
<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.
Fare has joined #commonlisp
<Bike>
yeah, i remember the early PCL docs mentioning it i think
<beach>
Good, that means i didn't dream that up. :)
Lycurgus has quit [Quit: Exeunt]
<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.
<subst>
Maybe I'll try the closure hack one day.
<beach>
Why would you want to do that now that all Common Lisp implementations have it? Specifically for Genera?
barthandelous has joined #commonlisp
<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.
<beach>
Sure.
<beach>
And I think we can do better than Genera on stock hardware.
<beach>
I mean, even with stock hardware, we can now do something better than Genera.
<beach>
That shouldn't stop you from trying your hack, of course.
lisp123 has quit [Ping timeout: 252 seconds]
amb007 has quit [Read error: Connection reset by peer]
amb007 has joined #commonlisp
<Bike>
if you can special case things in funcall and apply that might work out ok
dsk has quit [Ping timeout: 246 seconds]
dsk has joined #commonlisp
<subst>
beach, I'm watching Mezzano closely.
bpanthi977 has quit [Remote host closed the connection]
<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.
<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.
selwyn has quit [Read error: Connection reset by peer]
<shka>
you could run linux kernel in the user space, as an application and use it to control the hardware
<beach>
That would be good enough as well.
<shka>
you could have megakernel and microkernel operating system in the one system :-)
<shka>
and besides, realistically running unsafe code would require something like this anyway
<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.
<shka>
mmm, yes
<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.
<shka>
it is like that good part about the unix philosophy
<shka>
complex applications should arise by interactions of smaller programs
<shka>
while ideally, complex applications should arise by interaction of functions
<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?
<beach>
It didn't even work well at the time with batch applications. The entire `troff' pipe was a disaster.
<shka>
beach: technically it failed, but the mindset was there
<beach>
I suppose.
<beach>
But it can work with the more sophisticated interaction that is allowed between Lisp functions, compared to byte streams.
<shka>
if you could define anything you want and share it across the whole system a full fledged lisp object...
<shka>
well this is obviously better
amb007 has quit [Read error: Connection reset by peer]
<shka>
make the OS a clim application :D
<pjb>
beach: some unix applications have been written like that. Even GUI applications (thanks to X11 subwindows model).
amb007 has joined #commonlisp
amb007 has quit [Read error: Connection reset by peer]
amb007 has joined #commonlisp
bpanthi977 has joined #commonlisp
<pjb>
beach: I think writing monolithic applications is more a political problem.
<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.
derelict has joined #commonlisp
lisp123 has joined #commonlisp
<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.
<shka>
oh, apple will not do that because of how would you profit on selling parts of the applications in the iStore?
<pjb>
I guess, the name explains why it has been killed…
<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.
<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.
<pjb>
(but you can also interpret OpenStep/Cocoa like Android, as a system of objects).
<pjb>
beach: oh, sure, the unix pipes. No. But objects.
lisp123 has quit [Ping timeout: 258 seconds]
amb007 has quit [Ping timeout: 252 seconds]
<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.
amb007 has joined #commonlisp
<pjb>
beach: there are systems that still work like this. For example Postfix (MTA).
<shka>
i would argue that the last part of this statement describes the implementation of the unix philosophy, but not itself
<pjb>
So perhaps it's not easy in general, but there are use cases where it's appliable.
<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.
<pjb>
jcowan: you can add methods to return the type from closures.
<pjb>
But it's a partial solution.
<jcowan>
I meant while avoiding changes to ordinary functions altogether.
isekaijin has quit [Quit: WeeChat 3.2]
<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.
<jcowan>
Such is not the Way of Unix, Grasshopper! But they do it anyway.
<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.
<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.
<pjb>
So it's possible, and it gives good results (MH is shell-scriptable and quite nice).
varjag has joined #commonlisp
yitzi has joined #commonlisp
notzmv has joined #commonlisp
cage has joined #commonlisp
<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
<jcowan>
I know. Except that they program as if they were still on Windows.
<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)
<jcowan>
EVen those who haven't worked on Windows, becuse monolithic code is the prevailing orthodoxy.
<aeth>
jcowan: well, they program based on what their programming language's model thinks
<aeth>
So e.g. if you're a Lisp, you pretend that you're using a Lisp Machine
<aeth>
Just most wind up being scripting languages for the web and not very different from each other.
<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.
<jcowan>
But you do need some low-level enablers
greyrat has joined #commonlisp
lucerne has joined #commonlisp
<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.
amb007 has quit [Ping timeout: 272 seconds]
<jcowan>
Click-see new page, faster than the mind an update.
Josh_2 has joined #commonlisp
<Josh_2>
Hi
amb007 has joined #commonlisp
<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
waleee has joined #commonlisp
lucerne has quit [Quit: Bye]
<jcowan>
That included all the back-end database maintenance, because the database was the file system. Very fast, very robust, no server required.
Noisytoot has joined #commonlisp
notzmv has quit [Remote host closed the connection]
VincentVega has joined #commonlisp
lucerne has joined #commonlisp
VincentVega has quit [Client Quit]
<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.
<pjb>
Eg. on iOS you must go thru the AppStore, codesign, write up descriptive forms, wait for Apple's approval, etc.
<pjb>
(it's not only old CICS and JCL systems).
bpanthi977 has quit [Quit: bpanthi977]
<remexre>
am I failing at reading, or does clhs 11.1.2.1.2 not actually state (intern "FOO" :CL) should be an error?
<Bike>
I suppose I don't see anything explicitly saying such
<Bike>
11.1.2.1 could be read to mean that adding or removing _external_ symbols is not allowed, though
kevingal has quit [Remote host closed the connection]
amb007 has quit [Read error: Connection reset by peer]
<jcowan>
The title of that section is actually misleading: it's constraints on the external symbols of the cl package.
amb007 has joined #commonlisp
<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.
<remexre>
right, but (intern "FOO" :CL) would be creating an internal name, right?
<jcowan>
Yes. But then (export cl:foo) makes it external.
<jcowan>
I really don't think that the spec authors expected the cl package to be anything but immutable.
<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.
<polygon-op>
cl package is required to be locked
<polygon-op>
locking arbitrary packages by the programmer is an extension
<jcowan>
polygon-op: Per the standard?
<polygon-op>
yes
<polygon-op>
(I don't remember the section)
<aeth>
polygon-op: no, CL package external symbols are undefined behavior if you treat them as if they are not locked
<aeth>
Which means that portably, you have to treat it like it's locked because it will be in some implementations
<aeth>
So for you, the Lisp program/library author, you have to treat it as if it's locked. Implementations do not, though.
<jcowan>
As I said, that is all about what you can do with external cl: symbols. There is nothing about creating symbols there.
<jcowan>
(defparameter cl:foo nil) is the easiest way to do so.)
<jcowan>
(or try to do so)
<polygon-op>
I must have remembered wrong then, sorry
<jcowan>
It's a subtle point, the fact that immutable containers and immutable objects in the containers are independent.
<jcowan>
all four combinations are possible
<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
<aeth>
Programmers will use the worst style permitted by the language.
selwyn has joined #commonlisp
<jcowan>
True, but Fortran can be written in any language.
<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.)
contrapunctus has left #commonlisp [#commonlisp]
<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?)
<aeth>
And messing with implementation internals is, of course, implementation-specific rather than standard.
<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.
<aeth>
(well, #'CL:+ and #'CL:*)
<aeth>
Of course, the user might be able to, but now you can get mad at the user for abusing non-portable UB
contrapunctus has joined #commonlisp
AnimalClatter has quit [Ping timeout: 240 seconds]
AnimalClatter has joined #commonlisp
IPmonger has joined #commonlisp
Lycurgus has quit [Quit: Exeunt]
IPmonger has quit [Remote host closed the connection]
Alfr has joined #commonlisp
selwyn has quit [Read error: Connection reset by peer]
treflip has quit [Quit: good night]
Cymew has quit [Ping timeout: 240 seconds]
srhm has quit [Quit: Konversation terminated!]
Inline has joined #commonlisp
kakuhen has joined #commonlisp
amb007 has quit [Ping timeout: 258 seconds]
amb007 has joined #commonlisp
cage has quit [Quit: rcirc on GNU Emacs 27.1]
Inline has quit [Remote host closed the connection]
Inline has joined #commonlisp
attila_lendvai has quit [Read error: Connection reset by peer]
attila_lendvai has joined #commonlisp
ec has joined #commonlisp
srhm has joined #commonlisp
<pve>
Hey, are the internals of asdf documented somewhere? Or perhaps a tutorial on how to extend it?
learning-cl has joined #commonlisp
ec has quit [Remote host closed the connection]
ec has joined #commonlisp
<pranavats>
pve: There is a manual. How do you want to extend it?
<pranavats>
There are packages which extend it, such as literate-lisp which also document the extensions. You can take a look at those too.
<pve>
I *can* load systems with it, but I need to make it behave like ":serial t" when modifying files
lisp123 has quit [Remote host closed the connection]
lisp123 has joined #commonlisp
wheelsucker has quit [Remote host closed the connection]
<pranavats>
I see.
scymtym has quit [Ping timeout: 246 seconds]
<etimmons>
pve: asdf handles :serial t by remembering the previous component and adding it to the :depends-on list for the component currently being processed
<pve>
etimmons: hmm right, I would have expected (make-instance 'module ... :serial t) to work but apparently it doesn't
amb007 has quit [Ping timeout: 252 seconds]
<etimmons>
yeah, it'd be great if that could work!
<etimmons>
But system parsing is currently a bit of a nightmare
<pve>
etimmons: I had a look at your extension, it looks like it could improve on package-inferred-systems
<etimmons>
You may have luck extending `asdf::compute-component-children` to define your implicit components and then call-next-method
akoana has joined #commonlisp
<etimmons>
Just be warned that's not exported yet. We're planning to export it in ASDF 3.4.0, so it may change before then, but I doubt it
<etimmons>
(and it's only available in 3.3.5)
<etimmons>
Thanks! That's the primary motivation behind it.
<pve>
etimmons: ok, I'm at 3.3.3 currently
luna-is-here has quit [Quit: luna-is-here]
IAmRasputin has quit [Ping timeout: 252 seconds]
luna-is-here has joined #commonlisp
amb007 has joined #commonlisp
learning-cl has left #commonlisp [#commonlisp]
aeth has quit [Ping timeout: 252 seconds]
lisp123 has quit [Quit: Leaving...]
tyson2 has quit [Quit: ERC (IRC client for Emacs 27.2)]
gioyik has joined #commonlisp
shka has quit [Ping timeout: 252 seconds]
scymtym has joined #commonlisp
kpoeck has joined #commonlisp
attila_lendvai has quit [Ping timeout: 256 seconds]
tyson2 has joined #commonlisp
dsk has quit [Ping timeout: 252 seconds]
notzmv has joined #commonlisp
Lycurgus has joined #commonlisp
<pve>
etimmons: I got the serial thing to work, happy now :)
selwyn has joined #commonlisp
Lycurgus has quit [Quit: Exeunt]
frgo has quit [Remote host closed the connection]
frgo has joined #commonlisp
aeth has joined #commonlisp
pve has quit [Quit: leaving]
rgherdt has quit [Ping timeout: 240 seconds]
varjag has quit [Quit: ERC (IRC client for Emacs 28.0.50)]
Guest9407 has quit [Read error: Connection reset by peer]