<White_Flame>
anti_oop: a language wherein it's impossible to do OOP would likely not be turning complete. I built OOP on top of BASIC string encodings once.
gioyik has quit [Ping timeout: 260 seconds]
<_death>
where's object oriented brainfuck
MetaYan has joined #lisp
<White_Flame>
(also s/turning/turing/ :-P)
<aeth>
_death: Brainfuck is so easy to implement that it's probably one of the most extended languages out there
<aeth>
usually extended in the implementation and not within Brainfuck, though
<aeth>
_death: That's obviously not the only OOP BF, either
<_death>
so there is one?
<aeth>
probably
varjag has quit [Ping timeout: 240 seconds]
Jesin has quit [Quit: Leaving]
chocimir has quit [Ping timeout: 260 seconds]
<aeth>
If you've ever written a brainfuck you get bored once you're done and you either start optimizing it a ton or adding a bunch of extensions because there are plenty of characters left (but those do make comments harder to write).
<_death>
I once had a good use for brainfuck
<aeth>
It's mainly used to prove turing completeness
<aeth>
In this case, implementing OOP on top of Brainfuck in Brainfuck would be used to support White_Flame's claim about OOP
<pjb>
anti_oop: you will have a hard time finding a language that is not OO, given that closures are equivalent to objects. You must eliminiate all languages that have closures too…
<_death>
back then I was writing keygens, so I could interpret brainfuck code that implements the algorithm, and it would serve as a watermark against people ripping code
lucasb has quit [Quit: Connection closed for inactivity]
<pjb>
anti_oop: what about languages such as C, where you can do struct foo { void (*moo)(struct foo* self); int x } o ={&foo_moo,42}; o->moo(o); ? This is OOP in my book.
<pjb>
anti_oop: even in assembler, you can do OOP!
<Nilby>
My friend wrote an "Audible Objectible INTERCAL", an OOP INTERCAL with auido input and output.
<_death>
did it play Duran Duran
<Nilby>
No, but Barbarella would be a good name for the Lisp in pure lambda calculus I briefly considered writing in AO-INTERCAL. :-P
emphazizer has joined #lisp
Josh_2 has quit [Remote host closed the connection]
<_death>
fantastic voyage into the guts of lambda calculus
Danishman has joined #lisp
Jesin has joined #lisp
gioyik has joined #lisp
turona has quit [Ping timeout: 272 seconds]
turona has joined #lisp
gioyik has quit [Ping timeout: 260 seconds]
ebrasca has quit [Remote host closed the connection]
Bad_K4rMa has quit [Remote host closed the connection]
igemnace has joined #lisp
Bad_K4rMa has joined #lisp
Oladon has quit [Quit: Leaving.]
random-nick has quit [Ping timeout: 265 seconds]
shifty has joined #lisp
bitmapper has joined #lisp
chocimir has joined #lisp
emphazizer has quit [Quit: Leaving]
asdf_asdf_asdf has quit [Remote host closed the connection]
z147 has quit [Remote host closed the connection]
z147 has joined #lisp
gioyik has joined #lisp
v88m has quit [Ping timeout: 265 seconds]
gioyik has quit [Ping timeout: 265 seconds]
orivej has joined #lisp
refpga has quit [Read error: Connection reset by peer]
<aeth>
pjb: I agree that "impossible to write OOP" is an impossible standard, but there are some languages where OOP is not expected (though possible!) and others where it is the norm.
<aeth>
White_Flame: As far as Turing complete goes, that's not necessarily the case. On further thought, the whole Turing completeness thing afaik includes "write an interpreter for another language" so, yes, you could write an interpreter for an OOP-utilizing language in any language, but maybe there's some where it's impossible in the base language.
<aeth>
Obviously C and ASM give you too much power, as does CL even if CL had no CLOS.
<pjb>
You can design languages that are NOT Turing Complete.
<pjb>
It's difficult, but possible.
<pjb>
Make them useful in addition, is very difficult, but still possible.
<pjb>
At least, useful to some users…
<aeth>
pjb: Yeah, but my point is there could in theory be a Turing complete language where it is impossible to write OOP without writing an interpreter or compiler for another language. Not in a Lisp, though, since you could just use macros, reader macros, etc., to integrate quite well no matter what.
asdf_asdf_asdf has joined #lisp
<aeth>
pjb: Lots of languages add restrictions that low-level write-an-OS-in-it languages like C or ASM or even CL don't have.
statusf90 has quit [Quit: statusf90]
<aeth>
pjb: Although I guess you could argue that you could get OOP, it would just syntactically be ugly and out of place without something like real macros on top of s-expressions.
<dlowe>
I made a deliberately non-turing complete language as a MUD scripting language so it would be guaranteed to complete
<dlowe>
it wasn't hard, I just disallowed branching to earlier points
<aeth>
What's it take to make it turing incomplete? Could you just take a CL subset where e.g. LOOP always terminates after a finite number of times?
<dlowe>
Yeah, I don't know what pieces you'd have to remove from an existing language
EvW has quit [Ping timeout: 260 seconds]
<pjb>
Well, you could just do nothing, relying on the finitude of our computers and universe…
<dlowe>
it also wasn't general purpose and I could add things that looped as single commands
<pjb>
(loop) will finishi in 1e15 years…
<aeth>
dlowe: I can start to get a feeling for what would have to be removed. e.g. TAGBODY and any form with an implicit tagbody (e.g. PROGN) is out although DO could just remove that feature and still be mostly the same. LOOP, etc., would need to have to have a finite run. Recursion would either have to be impossible or restricted.
<dlowe>
if you can implement the y-combinator, you've already lost
<pjb>
Probably much earlier, like 4e9 years, when the Sun goes nova.
<Nilby>
Wouldn't you have to remove function calls?
<pjb>
Nilby: not if you don't guarantee that you can call a function. Eg. the C standard doesn't guarantee it, so C is not Turing Complete.
<aeth>
pjb: Theoretically, we assume that (loop) will be run on a redundant architecture that will never have to shut down, can be upgraded without shutting down the computation, can have the Lisp implementation be upgraded without restarting it, etc., to the point where even entropy itself will be reversed just to keep it running. Obviously impossible in practice. :-p
ebzzry has joined #lisp
Josh_2 has joined #lisp
<aeth>
pjb: We also assume that any limits (e.g. the maximum array size) will be upgraded in-place before the computation hits it, as well as the memory itself expanded when needed.
<aeth>
Just because the CL program can't run ideally in practice doesn't mean that the ideal running is impossible...
<_death>
updated with some bloop user code
<aeth>
There's a distinction between "(loop)" in theory and "(loop)" running on SBCL 2.0.0 on Fedora 31 on a Ryzen 9 3900X etc.
<aeth>
Btw, we need a parallel version of LOOP so that (ploop) can run on all 24 hardware threads simultaneously in an infinite loop...
<_death>
aeth: I used ackermann function for that
ralt has quit [Quit: Connection closed for inactivity]
<_death>
aeth: "practically infinite time"
<edgar-rft>
aeth: I'm curious how your parallel version of OOP would be called
<aeth>
edgar-rft: obviously PACOOP for Parallel and Concurrent OOP
bitmapper has quit [Ping timeout: 260 seconds]
whiteline has quit [Read error: Connection reset by peer]
whiteline has joined #lisp
Oladon has joined #lisp
gioyik has joined #lisp
orivej has quit [Ping timeout: 268 seconds]
v88m has joined #lisp
asarch has quit [Quit: Leaving]
v88m has quit [Ping timeout: 260 seconds]
davepdotorg has joined #lisp
ebzzry has quit [Ping timeout: 240 seconds]
cg505 has quit [Ping timeout: 260 seconds]
cg505 has joined #lisp
davepdotorg has quit [Ping timeout: 268 seconds]
igemnace has quit [Quit: WeeChat 2.7]
orivej has joined #lisp
anti_oop has quit [Remote host closed the connection]
gioyik has quit [Ping timeout: 265 seconds]
efm has quit [Remote host closed the connection]
efm has joined #lisp
Bad_K4rMa has quit [Remote host closed the connection]
adamantium has joined #lisp
z147 has quit [Ping timeout: 240 seconds]
v88m has joined #lisp
dale has joined #lisp
madrik has quit [Ping timeout: 268 seconds]
gioyik has joined #lisp
igemnace has joined #lisp
chocimir has quit [Ping timeout: 240 seconds]
asdf_asdf_asdf has quit [Quit: asdf_asdf_asdf]
chocimir has joined #lisp
<beach>
Good morning everyone!
<drmeister>
Hi beach.
<drmeister>
I got Clasp working with the Memory Pool System garbage collector!
<drmeister>
It only took six years.
<pjb>
Well done!
<drmeister>
Moving garbage collectors and hash-tables are complicated.
<no-defun-allowed>
Congratulations!
chocimir has quit [Read error: Connection reset by peer]
<drmeister>
Oh and thread safe hash-tables with a moving garbage collector.
<drmeister>
Thank you all.
<no-defun-allowed>
Indeed.
<drmeister>
My perception of hash-tables has changed completely.
<drmeister>
They aren't these precise data structures where every key/value pair is in a precise place.
<no-defun-allowed>
Yep.
<drmeister>
They are these loosy-goosy bags of key/value pairs that sometimes let you lookup the key faster - but they have to be rehashed whenever their keys go stale.
<no-defun-allowed>
Not long ago, I wrote a program that would pick keys that hashed to the same bucket in Clozure, making hash tables only about as fast as alists.
<no-defun-allowed>
Analysing how that and SBCL implemented hash tables led me to the same conclusion.
<drmeister>
I'd like to learn more about how SBCL implements hash tables.
<drmeister>
I'll follow your advice and check out src/code/hash-table.lisp
<drmeister>
Right now I'm reading legal documents - ugh.
<no-defun-allowed>
That file has nice ASCII diagrams of the vectors' contents, too.
<drmeister>
Red wine helps quiet the voices in my head enough to read - but doesn't help with comprehension.
<drmeister>
Oh - neat. I like pictures.
davepdotorg has joined #lisp
<no-defun-allowed>
You can't be having too much fun.
<drmeister>
I can't complain.
<drmeister>
Or I can - but lots of other people have more legitimate complaints.
<no-defun-allowed>
A friend told me that threads in Java-land have their own class loaders and thus class identities, so I have to work out some gymnastics to get ABCL to be able to read the right net.minecraft.client.Minecraft to get the only not-a-God-object instance of it.
ggole has joined #lisp
torbo has quit [Remote host closed the connection]
<no-defun-allowed>
Sure.
davepdotorg has quit [Ping timeout: 265 seconds]
nullman has quit [Ping timeout: 268 seconds]
nullman has joined #lisp
akoana has joined #lisp
varjag has joined #lisp
<beach>
drmeister: Congratulations!
<beach>
For what it's worth, my plan is to promote keys to the global heap, where they will no longer move) before computing a hash value for them.
<drmeister>
All keys?
<beach>
Yes.
<drmeister>
Thank you by the way.
<beach>
Since that mechanism is required anyway, no additional logic is necessary.
varjag has quit [Ping timeout: 268 seconds]
<drmeister>
location dependency is a headache.
<beach>
I have no experience with it, but it sounds messy, so I plan to avoid the mess.
<drmeister>
It was fortunate that I had this HashGenerator class that accumulates components of hashes and then calculates the hash at the end. I was able to add a method to add addresses and then later I can check if any of the addresses are stale.
<beach>
I wonder how much people factor in GC performance when they decide how to represent data.
krid has quit [Ping timeout: 268 seconds]
<drmeister>
But man - i did not appreciate the complexity of implementing an EQ hash table with with objects moving around and multiple threads.
<beach>
What you are saying makes me confident that my plan is the right one.
<drmeister>
I'm not going to write a garbage collector anytime soon. So I use what I have.
<drmeister>
Clasp supports two GC's now.
<beach>
Sure.
<drmeister>
Our multithreaded compiler is really strangled by the Boehm GC. I'm really curious to see how it performs with MPS.
<drmeister>
The MPS uses bump allocation and each thread has a separate set of allocators.
<beach>
And the question I asked my self when offered by Nick Levine to use MPS was the relative complication of writing a GC or using MPS, which the additional complications for hash tables.
<beach>
I don't have the answer yet.
<beach>
GCs are notoriously hard to debug.
<aeth>
GCs basically take all of the effort that makes something like C hard, and puts the burden on the GC library instead of the language user. So thank you, GC authors.
<beach>
aeth: Now if we could just convince people who use languages with manual memory management for application development that this is the case.
kark has joined #lisp
<aeth>
I spend quite a bit of time debugging memory issues when I write C or C++. Probably most of my debugging time. Those can be hard.
<beach>
I even consulted with a company where the project leaders used a moral argument. They thought that programmers should be morally obliged to clean up the memory they allocate.
<beach>
I didn't want to ask them how they could rely on the compiler emitting code to remove arguments from the stack after a function call, rather than making the programmer do it.
ggole has quit [Read error: Connection reset by peer]
<aeth>
It's already mostly 2x-5x within C/Rust/C++, and this is microoptimized hyper-optimized benchmark code, not code you'd see in production
ggole has joined #lisp
<beach>
aeth: No, the most common argument is based on "gut feeling" with no statistical data whatsoever. And that gut feeling is typically wrong.
Bike has quit [Quit: Lost terminal]
<aeth>
beach: Yes, but the most common rational arguments (or at least rationalizations) could be addressed with real-time garbage collection (the Java world is several steps ahead of us here) and improvement in overall language performance.
<aeth>
GCC has a head start in performance, but the more you optimize, the more diminishing returns you get, so most languages should catch up within 15 years imo.
<beach>
Part of the gut feeling has to do with thinking that malloc/free are very cheap.
<aeth>
As far as performance goes, Rust is the first to catch up with C/C++, but it's not going to be the last...
<beach>
Also the typical arguments do not attempt to take into account development and maintenance effort.
<aeth>
beach: Absolutely.
<beach>
They all assume an unbounded amount of resources in a small period of time.
<aeth>
beach: Even taking 3x to 5x slower than GCC C at face value (production C is not going to be as hyperoptimized as microbenchmarks), that's more than fine for just about every application. There's probably 25-30 languages that have implementations that are fast enough for almost everything.
<aeth>
beach: So, yes, maintenance effort is absolutely more important, especially for software maintained for 15-20 years.
<aeth>
Well, really, unbound years.
<aeth>
It doesn't help that what most people have in mind as C alternatives tend to have incredibly slow implementations, though.
<beach>
And those tiny benchmarks don't take into account the cost of doing reference counting or copying of data, or smart pointers, or ..., which will have to be introduced if the code is to be modular.
<aeth>
beach: Right, but winning at some tiny benchmarks is probably a necessary step in convincing people that Common Lisp can be fast enough. I think most people assume all Lisps are interpreted!
<aeth>
beach: A more serious performance issue is probably providing different GCs for different tasks (including RTGC), which the JVM now does. Performance complaints are valid here.
Necktwi has quit [Ping timeout: 265 seconds]
FreeBirdLjj has joined #lisp
<aeth>
SIMD is probably the next priority after better GC as far as "valid reasons to use GCC over SBCL" go
zaquest has quit [Quit: Leaving]
ggole has quit [Remote host closed the connection]
ggole has joined #lisp
oxum has quit [Remote host closed the connection]
vlatkoB has joined #lisp
scymtym has quit [Remote host closed the connection]
<beach>
Or, you can just give up trying to convince people. Given the strong psychological forces involved, there is little chance that facts will do the trick.
zaquest has joined #lisp
ebzzry has joined #lisp
<beach>
I am personally convinced that the only thing that will work (for some value of "work") is to show what can be done by producing good code, with good functionality, with less effort than what is possible with a language with manual memory management.
gravicappa has joined #lisp
<no-defun-allowed>
Isn't there also that one paper that manual memory management apologists love to use that claims something like a 6x memory overhead?
<no-defun-allowed>
I think I tried to read it, then inferred they treated calling malloc/free as "free", which is absolute shite.
<beach>
I haven't seen that, but arguments like that are usually based on old GC technology.
oxum has quit [Read error: Connection reset by peer]
<beach>
Also, arguments without any comparison are pretty useless. I am reminded of the current debate here in France as to whether country roads should allow 80km/h or 90km/h. The debate is endless, because nobody dares set a price on a human life, which is what it boils down to.
<no-defun-allowed>
I think you're right; the paper states "Steele observes garbage collection overheads in LISP [sic] accounting for around 30% of application runtime [30]." and it cites Steele's 1975 paper on parallel compacting.
oxum has joined #lisp
<beach>
I mean 80km/h lowers the annual death toll, great! But 70 even more so, and 60 even more....
oxum has quit [Read error: Connection reset by peer]
gnufr33d0m has joined #lisp
<beach>
So that additional memory, how much does it cost, compared to the savings in development effort.
oxum has joined #lisp
<beach>
Again, they assume that development and maintenance is free, and they are not willing to set a price on it, much like the French government does not dare put a price on a human life.
<no-defun-allowed>
"We show that GenMS, an Appel-style generational collector witha mark-sweep mature space, matches or exceeds (by up to 9%) the runtime performance of the best explicit memory manager when given five times as much memory." Something must be seriously wrong with that experiment, but I don't have a paper.
<no-defun-allowed>
But that also compares it to an "oracle", which will not exist for most programs.
<beach>
Not necessarily. There is a valid theorem that GC cost tends asymptotically to 0 when the size of the memory increases.
<beach>
And that is valid for mark-and-sweep as well as for copying collectors.
<beach>
So it looks like someone picked a memory size that will beat the "explicit" scheme.
<no-defun-allowed>
Sure, Appel wrote about it, and he computed the "crossover" point to be 7× the size of the live set.
brown121408 has quit [Ping timeout: 240 seconds]
<beach>
But again, they are saying that for automatic memory management to be valid, its performance must be better than that of "explicit" memory management, assuming that everything else (like maintenance cost) is constant.
<beach>
... just like the French government assumes that there is no loss of time and productivity when the speed limit is lowered.
brown121407 has joined #lisp
<no-defun-allowed>
Maybe if an inverse statement was made, like, "The GenMS collector exhibits only a n% slowdown when provided the same memory size as an oracle-based memory manager", then the generalisations would not be as bad.
<beach>
That's not enough. Development cost, memory cost, and estimated number of deployed versions of the software must be taken into account.
<beach>
Clearly if you have millions of installations and each installation has to buy more memory, and provided you can charge a little more for the software, then you can spend much more effort on development.
<beach>
If you have only a few installations, it is highly unlikely that additional development cost will be cheaper than the additional memory those installations require.
<no-defun-allowed>
Sure.
Oladon has quit [Quit: Leaving.]
<beach>
... just as you would have to take into account the length of the stretch of road when you decide on the speed limit.
<beach>
Otherwise, you are back to the standard argument I hear in the industry, namely "we need all the speed we can get", which is false, but especially, it lead to completely absurd decisions with respect to development.
<beach>
I mean, forget about C++. You need to do everything in assembly, for starters. Then you need to hire LOTS of excellent programmers for a VERY LONG TIME.
<pjb>
0 km/h lowers the annual death toll to the absolute minimum possible. Basically, 1 or 2 death, by meteorite drop or static car explosions.
<pjb>
There should be a speed limit on meteorites too…
<p_l>
beach: these days there's little push for C++ outside of few places which rarely would accept lisp anyway and where there's sunk cost of significant amount of libs and actual realtime performance issues
<p_l>
usually it's all about development speed, except it leads to applications developed in shitty JS in Electron environment
<no-defun-allowed>
pjb: "You" could also improve the safety of vehicles or educate the drivers better to have utility and less deaths, but that's no good if you're hitting someone with a car; nor does the analogy work as you cannot create a memory management oracle.
jello_pudding has joined #lisp
<beach>
p_l: And that's a good evolution, because now, real comparisons can be made. Who was it (Steele?) that said something like "with Java, we managed to drag them half way to Lisp"?
<no-defun-allowed>
That was Steele.
davepdotorg has joined #lisp
<beach>
p_l: But a similar argument applies. That sunk cost must be taken into account, but only as one factor. Another typical argument is that it is infinitely costly to train programmers (but not expressed that way).
<p_l>
beach: well, the main remaining place for C++ that is not through legacy code is games
davepdotorg has quit [Ping timeout: 240 seconds]
jello_pudding has quit [Quit: Quit]
jello_pudding has joined #lisp
jello_pudding has quit [Client Quit]
adamantium has quit [Remote host closed the connection]
jello_pudding has joined #lisp
akoana has left #lisp ["Leaving"]
jello_pudding has quit [Quit: Quitting Client]
<beach>
p_l: So then we should just dismiss benchmarks between "explicit" and automatic memory managment.
<beach>
management.
<p_l>
not really... because properly done they show manual losing ;)
<p_l>
benchmarks on various GC schemes are important to tuning them
<beach>
But if (almost) nobody is using such languages, who cares?
<p_l>
however, majority of programmers don't need them till they hit a performance problem, and in many cases there's no choice in algorithms, so you are left with profiler
<beach>
You can't have it both ways.
<p_l>
beach: manually-managed runtimes are a minority
<p_l>
C/C++ is a minority
<p_l>
most new Pascal code uses GC
<p_l>
Objective-C uses primitive schemes like refcounting
<p_l>
pretty much everything else used in desktop or server applications uses GC
narimiran has joined #lisp
<p_l>
(or refcount or refcount plus simple GC)
<p_l>
IMHO, GC is not a battle to be won - because it's already won outside of certain niches
<beach>
So why are we still discussing those benchmarks?
<beach>
We should just use your argument. TADA!
<p_l>
beach: because programmers that are vocal about such things are, well, vocal?
<beach>
I am not saying you are wrong. On the contrary. I am not as well informed as you are.
<beach>
Who cares how vocal they are if they are a tiny minority.
<p_l>
another thing is that some benchmarks are done for the purpose of analysing the state of the art, and are then taken by some people who run crazy with it
<p_l>
beach: they are *heard* minority
<beach>
Again, you can't have it both ways.
<beach>
Either the battle is won or it is not.
<p_l>
and sometimes you have people who might work in tech X but often claim views against it
<beach>
I can go either way, because I am not well informed. But it can't be both.
<p_l>
beach: it also doesn't help that there's a certain well known and popular platform that happens to use GC but which, unrelated to GC, sucks so hard it's not funny
<p_l>
(and no it's not Java)
<beach>
That's a very different argument.
<p_l>
yes
<p_l>
but it stokes the fire under "if we used manual memory management it would be better"
<beach>
I see.
<p_l>
also, to be frank, GCs in Common Lisp, at least in open-source implementations, are kinda on the lower end of capability
<p_l>
but that's a total aside
georgie has joined #lisp
<beach>
Indeed. Most such implementations were written long ago.
adamantium has joined #lisp
shka_ has joined #lisp
<p_l>
still they tend to work pretty well
georgie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
oxum_ has joined #lisp
oxum has quit [Read error: Connection reset by peer]
jprajzne has quit [Quit: jprajzne]
oxum_ has quit [Remote host closed the connection]
oxum has joined #lisp
oxum has quit [Read error: Connection reset by peer]
oxum has joined #lisp
varjag has joined #lisp
shka_ has quit [Ping timeout: 265 seconds]
gioyik has quit [Quit: WeeChat 2.7]
<aeth>
beach: You're right about people not really being convinced. The thing that is most "convincing" as far as programming languages go is not giving people a choice. Most popular languages are the only real choice for a platform, most notably JavaScript. But even with e.g. Python, its high-quality libraries drive people there for various niches, such as machine learning.
<aeth>
p_l: Real-time manual memory management can be beaten, too, it's just that it's a niche so the focus on GCs weren't really there until recently. Now that it's the main remaining justified niche for C++, it's slowly being tackled. As I mentioned earlier, the JVM now has configurable GC so you can choose that e.g. your application is real-time so use the RTGC.
<aeth>
Hopefully Lisp implementations will catch up.
<beach>
I don't buy that argument. I have never seen a project cost estimate that takes into account the cost of implementing a language for a platform where it does not exist yet.
emys has joined #lisp
<beach>
aeth: Just as I never see a project cost estimate that takes into account the cost of training programmers in a different language.
<aeth>
p_l: Another thing is explicit layout of bytes, which C# (not Java) has gotten fairly good at doing afaik iirc. Most of the time you don't want that, but when you need to micromanage it, you can use certain exposed data structures.
<p_l>
beach: I think I've seen two or three where "we need to port our chosen language" was involved
<p_l>
also, real time and real time differ :)
<aeth>
beach: No, my point is that a platform drives people to a language (e.g. JavaScript in web browsers) and then once a lot of people know that language, they then try to use that language elsewhere because they're attached to it (e.g. node.js)
varjag has quit [Ping timeout: 265 seconds]
<aeth>
So platforms seem to drive popularity in "new" languages (new relative to C)
<beach>
aeth: Yes, but they should put a price tag on that attachment. Which they don't.
dale has quit [Quit: My computer has gone to sleep]
<p_l>
portability is why I don't intend to write anything in Rust anytime soon
<beach>
Aside from "we need all the speed we can get" I also see "all our programmers already know X".
<beach>
And I guess I should add "Our target platform only has X on it."
<beach>
... thereby assigning infinite costs to alternatives.
<jeosol>
By the way, I am enjoying this conversation about language choice given that I chose to use CL (because of CLOS) and Paul Graham recommended Clojure when I asked him. I recently investigated react. It's definitely led to rewiring some of my neurons, not easy to follow
<aeth>
more people need Mezzano as their target platform...
<p_l>
ABCL and Clojure open up a lot of platforms
<jeosol>
but I no front-end expert. I have gotten involved in language wars also, given I use CL, and when people see me using emacs+slime, they wonder what is this obscure language I am using
<aeth>
beach: To be fair, those first two are some of the reasons why I use SBCL. I need all the speed I can get, and I know CL.
<aeth>
beach: Now I just need to make a target platform for SBCL ;-)
<no-defun-allowed>
Graham avoids CLOS in CL, which is very strange. (...or was that Norvig?)
<aeth>
Of course, I'm joking a bit. It's a somewhat different matter to choose an implementation of a portable language because it's the fastest, rather than choosing a language because it has fast implementations.
<aeth>
no-defun-allowed: Yeah, I noticed the contradiction too. (In that jeosol likes CL because of CLOS and pg?)
<aeth>
Because pg is very anti-CLOS
<jeosol>
Yes, it led to be twitter back and forth when I asked Graham, but after I clarified my application was using CLOS heavily, it did admit and conceded that, I should proceed with CL then.
<no-defun-allowed>
Baker already made the CLOStrophobic pun (for other reasons) but Graham does seem to have a case of CLOStrophobia.
<jeosol>
no-defun-allowed: thanks for that clarification, I didn't know at the time
<jeosol>
or even suspected. My main issue (before I got far) was about deployment. I was very early in the journey
oxum has quit [Remote host closed the connection]
JohnMS_WORK has joined #lisp
<jeosol>
how have you guys dealt with the issue of, not many CL programmers, or people don't want to learn this old language.
emys has quit [Ping timeout: 240 seconds]
<jeosol>
viz-a-viz interop with other systems
<jeosol>
aeth: what do you mean by target platform for SBCL ?
<aeth>
jeosol: well, I mean a target platform utilizing SBCL
<aeth>
since now that will hit all 3 of 3 checkboxes for why to use a language
georgie has joined #lisp
adamantium has quit [Remote host closed the connection]
adamantium has joined #lisp
<jeosol>
Thanks for clarifying. I see what you mean. the "3 of 3 checkboxes" discussed earlier I assume?
<aeth>
I was attempting to joke.
<jeosol>
I have had a hard time convincing people given that they never programmed in CL. I guess I need to do a better job articulating my choice of language
<beach>
jeosol: In my experience, convincing people won't work. The only thing that works is to show them good results yourself.
<Shinmera>
what beach said.
<aeth>
jeosol: There is no convincing most people, most people use a language to do something rather than picking languages based on design characteristics. If you really wanted to convince people, write a library they want to use or an application they want to modify/script.
<jeosol>
beach: I have the good results. i.e., the proof, it's what I am currently working on
<aeth>
We already see what makes languages popular in the most popular Lisp: Emacs Lisp.
<beach>
jeosol: Excellent!
<beach>
jeosol: Then you can just sit back and wait. Those who want to be convinced will come to you.
emys has joined #lisp
<aeth>
Objectively imo Emacs Lisp is possibly the worst living Lisp language, but it's the most popular at least on Github, mostly poor quality configuration/scripting of Emacs. Quantity, not quality, but you can't deny the popularity.
<aeth>
And people use it because they have to.
<jeosol>
I did start with matlab, then C++, then eventually CL. Writing a complex application in CL was smooth (of course, after I mastered CLOS and other aspects of the lang).
<aeth>
A complex application in CL can be entirely written within LOOP!
<jeosol>
beach: thanks for that. I am in the process of the proving now. with slime + emacs, one M- . much easier to navigate to functions, fix errors.
<jeosol>
I think have some improvements to make. I was recently having a chat with Fare about parallel compilation to make things faster and reducing the package dependencies. he told me to look at POIU and asdf-grovel--? something like that.
<Nilby>
asdf-grovel-dependencies maybe?
<jeosol>
Shinmera, aeth, beach: thanks, I will just avoid proviing anything
<jeosol>
Nilby: that's it. asdf-grovel-dependency
<Nilby>
I really wish asdf-grovel-dependency worked flawlessly.
gnufr33d0m has quit [Quit: gnufr33d0m]
<jeosol>
Nilby: you used it before. I didn't see a lot examples, in my limited search
<Nilby>
If it was combined with beach's Eclector it might be better.
<jeosol>
ok, I need to look Eclector up
<jeosol>
Fare did provide pointers, but did warn me that it will take some effort. I haven't hard time yet.
<Nilby>
It's one of those things which would be nice, but would be a lot of work to get right, so everyone just does manual dependencies.
<beach>
Nilby: It is scymtym's Eclector now.
flamebeard has joined #lisp
emys has quit [Ping timeout: 265 seconds]
<Nilby>
beach: Ah, sorry, I'm bad at keeping up on who's working on what. I guess if it's in quicklisp it's everybody's now.
<beach>
Oh, is it in Quicklisp?
<beach>
I tend to forget.
georgie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
oxum has joined #lisp
jprajzne has joined #lisp
emys has joined #lisp
karlosz has quit [Quit: karlosz]
karlosz has joined #lisp
Duuqnd has joined #lisp
madrik has joined #lisp
Cymew has joined #lisp
easye has quit [Quit: ERC (IRC client for Emacs 26.3)]
oxum has quit [Remote host closed the connection]
davepdotorg has joined #lisp
easye has joined #lisp
akrl`` has joined #lisp
stux|RC-- has joined #lisp
asarch has joined #lisp
stux|RC has quit [Ping timeout: 240 seconds]
<asarch>
One stupid question: is C
<Shinmera>
It's been on QL for over a year now :)
davepdotorg has quit [Ping timeout: 268 seconds]
akrl` has quit [Ping timeout: 260 seconds]
Oddity has quit [Ping timeout: 260 seconds]
<asarch>
I mean, is C++'s STL considered a "metaobject protocol"?
emys has quit [Read error: Connection timed out]
dddddd has quit [Ping timeout: 260 seconds]
<jackdaniel>
I've never heard anyone calling it that, so no
<jackdaniel>
at least as far as I'm aware
Nistur has quit [Ping timeout: 260 seconds]
<pjb>
asarch: nope. There's a MOP for C++. But it has bitrotten.
<beach>
asarch: I am curious as to why you care about what is named what?
copec has quit [*.net *.split]
Intensity has quit [*.net *.split]
<beach>
asarch: Why is it not enough to know what you can do with each thing?
<beach>
asarch: Are you involved in some argument with other people?
<pjb>
Or it's a mapper strategy, to classify things…
<beach>
Or that, but for what purpose?
<pjb>
Learning.
<beach>
asarch: Are you writing a book?
Oddity has joined #lisp
<beach>
asarch: And if you program in Common Lisp, why do you care about STL and C++?
Nistur has joined #lisp
Tordek has quit [Ping timeout: 260 seconds]
<beach>
asarch: I mean, your latest question, I would have phrased something like "what characterizes a metaobject protocol", and then I would have checked whether STL fits the description.
georgiePorgie has joined #lisp
<no-defun-allowed>
I don't think STL does anything like a metaobject protocol.
Player_one has joined #lisp
<beach>
Of course, but it's still a strange way of asking.
Player_one has quit [Remote host closed the connection]
<no-defun-allowed>
The C++ object system is very much a compile-time object system; I think it is unlikely you can create a MOP there.
<beach>
I would encourage asarch to learn about the characteristics I was talking about, rather than collecting a list of yes/no items.
Nistur has quit [Remote host closed the connection]
jello_pudding has joined #lisp
<beach>
Perhaps asarch isn't even interested in the answers. Maybe it's all meant to keep other #lisp participants busy.
<Nilby>
I just double checked, in case they added something. C++ in no way has a MOP.
copec has joined #lisp
Intensity has joined #lisp
<beach>
If so, it's working.
ralt has joined #lisp
Oddity has quit [Ping timeout: 260 seconds]
Nistur has joined #lisp
Tordek has joined #lisp
karlosz has quit [Quit: karlosz]
Oddity has joined #lisp
<p_l>
the simple answer is that STL is in no way a metaobject protocol, and I think C++ native objects make it impossible to implement one unless it's hosted on top of a system using one to implement C++
<p_l>
(the latter would fall close to OpenC++)
<Shinmera>
Qt and GTK have their own versions of something approaching a "mop".
<p_l>
GTK implements its own object system so it can provide a metaobject layer for it (as you can grab the implementation code and choke the metaobject out of it) but it's not self-hosting metaobject
<jackdaniel>
if you are interested in this kind of stuff you may take a look at eobject protocols in efl libraries
<p_l>
Qt's metaobject support is more about implementing certain behaviours as metaclass for all classes in a hierarchy while avoiding certain issues of the C++ as language, but it's also not self-hosting, and iirc less capable than OpenC++
<Nilby>
Qt used to have to pre-process C++ to even call methods properly, maybe it still does?
<asarch>
Well, it turns I am reading (once again) the "The Art of the Metaobject Protocol" book
<asarch>
And in the prologue the book says that a metaobject is a "collection" of classes that "helps and makes" the life of a programmer easier
<beach>
Yes, but that's not ALL it is.
<Cymew>
Weak sauce. I want my classes to hinder me, and make me stronger!
emys has quit [Ping timeout: 240 seconds]
<Shinmera>
Cymew: Java exists
<asarch>
So, if C++'s STL is not a MOP at all, what exactly is a MOP?
<asarch>
Would you consider the old Borland's OWL (ObjectWindow Library) as a MOP?
<beach>
asarch: Stop it please.
<no-defun-allowed>
Uhm, a meta-object protocol relates to how classes and generic functions work together, more or less.
<beach>
asarch: Read the book.
<p_l>
asarch: the more formal definition is that a MetaObject system is how the object system is implemented, i.e. it's object system defining the object system, preferably in metacircular way
davepdotorg has joined #lisp
davepdotorg has quit [Remote host closed the connection]
davepdot_ has joined #lisp
<beach>
asarch: It means that the entire object system is written in itself, and that it allows for the user to adapt and extend it using the same tools as the MOP proposes for application development .
<asarch>
For example this sentence: "Augmenting a language with a metaobject protocol does not need to be a radical change. In many cases, problems with an existing language or implementation can be improved by gradually introducing metaobject protocol features"
<no-defun-allowed>
One common-ish use of the Meta Object Protocol in Common Lisp is to create metaclasses which allow classes to be serialised to a database or text format, with the client adding hints where necessary into the class definition.
<no-defun-allowed>
That would be difficult with C++, and probably not related at all to the STL or OWL.
emys has joined #lisp
<asarch>
I thought "metaclasses" were the same as "abstract classes" (or even "templates") :-(
<no-defun-allowed>
Not really.
adamantium has quit [Remote host closed the connection]
<p_l>
C++ templates are really separate from the whole "object" model of C++. abstract classes are just a certain pattern in inheritance-heavy programming
<no-defun-allowed>
A class is an instance of a metaclass, like an instance is an instance of a class. (Then a metaclass is a class which is an instance of a metaclass, so you get some circularity.)
<Cymew>
Shinmera: Good point.
<jackdaniel>
despite seeing word mop splattered all over the place I can't help but see an offtopic discussion
<pjb>
asarch: you thought wrong.
oni-on-ion has quit [Remote host closed the connection]
oni-on-ion has joined #lisp
<pjb>
asarch: abstract classes are classes that cannot have instances. templates are not classes, they're copy-paste programming in a fashion.
<pjb>
asarch: metaclasses are the classes of the classes. There, classes are objects like any other object.
* asarch
takes notes...
<pjb>
asarch: in C++, classes are not object. You cannot declare in your program a variable to hold a class, and do things with it. (You can do it in templates but there classes are considered just as types).
<Cymew>
jackdaniel: Serious question. Is MOP ever talkd about outside of Common Lisp? I don't know.
<pjb>
asarch: the MOP let you define new metaclasses that let you create different *kinds* of classes.
<pjb>
Cymew: see OpenC++ link above.
<jackdaniel>
Cymew: it is discussed in "other lisps"
<jackdaniel>
i.e Lisp in Small Pieces discusses MOP
<asarch>
Does Smalltalk-80 has its own MOP? (you know, CLOS was inspired in the Smalltalk classes which actually were inspired in CLOS...)
<Cymew>
I have been illuminated.
<pjb>
Cymew: also, it's a fundamental feature of Smalltalk.
<jackdaniel>
EuLisp standard defines its own MOP
<jackdaniel>
etc
<no-defun-allowed>
Smalltalk and I believe Python to some extent.
<Cymew>
Thanks.
adamantium has joined #lisp
<pjb>
asarch: to understand the MOP, just try to implement an object system yourself.
<asarch>
"You cannot declare in your program a variable to hold a class, and do things with it." <- These are "first-class classes", right?
<pjb>
Yes.
<no-defun-allowed>
If you replace "cannot" with "can", then yes.
<asarch>
Does Common Lisp support them?
<pjb>
Once you can do that, you could send messages to a class to do various things, such as, add new methods, replace methods, add slots, scan slots for slots of a given type and generate methods for them, etc.
<pjb>
Of course.
<asarch>
How?
<no-defun-allowed>
(defvar *my-very-dearest-class* (find-class 'standard-class)) ; You tell me.
adamanti` has joined #lisp
adamantium has quit [Read error: Connection reset by peer]
<asarch>
Wow! I've seen this example in Python with SQLAlchemy so far: Session = create_session(...); session = Session();
<pjb>
(defclass foo () (x y z)) (let ((class (find-class 'foo))) (c2mop:class-direct-slots class)) #| --> (#<standard-direct-slot-definition for instance slot x #x30200293D4CD> #<standard-direct-slot-definition for instance slot y #x30200293D43D> #<standard-direct-slot-definition for instance slot z #x30200293D3AD>) |#
<asarch>
What is the name of the Smalltalk's MOP?
<pjb>
asarch: now in the case of CLOS, methods are not attached to classes, but to generic functions. But it would be trivial to define a metaclass to put methods into classes, and to (single) dispatch like in Smalltalk. Since you are reading the "The Art of the Metaobject Protocol", you should do just that as an exercise.
<asarch>
Now I understand the C++'s mock "worse is better"
space_otter has quit [Remote host closed the connection]
<asarch>
There are so many other great features to discover
_whitelogger has joined #lisp
emys has quit [Ping timeout: 240 seconds]
<no-defun-allowed>
What's Moose?
<jackdaniel>
asarch: this is offtopic on this channel, you may move it to #lispcafe or #perl channel
<asarch>
Sorry :-(
<beach>
asarch: The key idea with Common Lisp classes is to realize that a class is just a model for creating objects, so when this idea is taken to its extreme, a class is just an object that can be given as an argument to the generic function MAKE-INSTANCE.
<beach>
asarch: It is in this respect that classes are first-class objects in Common Lisp.
<beach>
It would have been much harder to do it any other way.
emys has joined #lisp
<asarch>
"A class is just a model for creating objects" <- Wow! So powerful! Is there other way to create them?
<beach>
In Common Lisp, instances of built-in classes are created differently.
<asarch>
The book talks about other ways before CLOS
<beach>
asarch: Like using CONS, MAKE-ARRAY, GENSYM, MAKE-HASH-TABLE, etc.
z147 has joined #lisp
madrik has quit [Ping timeout: 265 seconds]
emys has quit [Ping timeout: 252 seconds]
varjag has joined #lisp
tiwEllien has joined #lisp
oxum has joined #lisp
m00natic has joined #lisp
<ralt>
to answer to no-defun-allowed, Moose is a widely-used Perl library to make perl much more OOPy
_whitelogger has joined #lisp
akoana has joined #lisp
georgiePorgie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
cosimone has joined #lisp
<asarch>
Well, thank you guys. Thank you very much
<asarch>
Have a nice day :-)
asarch has quit [Quit: Leaving]
oxum_ has joined #lisp
oxum has quit [Read error: Connection reset by peer]
oxum_ has quit [Remote host closed the connection]
statusf90 has quit [Quit: statusf90]
oxum has joined #lisp
glv has joined #lisp
oxum_ has joined #lisp
oxum has quit [Remote host closed the connection]
orivej has quit [Ping timeout: 265 seconds]
oxum_ has quit [Remote host closed the connection]
v88m has quit [Ping timeout: 260 seconds]
akrl`` has quit [Remote host closed the connection]
akrl`` has joined #lisp
oxum has joined #lisp
random-nick has joined #lisp
akrl`` has quit [Remote host closed the connection]
akrl`` has joined #lisp
adamantium has quit [Remote host closed the connection]
adamantium has joined #lisp
cosimone has quit [Quit: Terminated!]
JohnMS has joined #lisp
jonatack has quit [Ping timeout: 272 seconds]
JohnMS_WORK has quit [Ping timeout: 268 seconds]
ljavorsk_ has joined #lisp
oxum has quit [Read error: Connection reset by peer]
oxum_ has joined #lisp
igemnace has quit [Quit: WeeChat 2.7]
longshi has joined #lisp
EvW1 has joined #lisp
edgar-rft has quit [Quit: Leaving]
jonatack has joined #lisp
pjb has quit [Remote host closed the connection]
pjb has joined #lisp
Nilby has quit [Read error: Connection reset by peer]
montaropdf has joined #lisp
dddddd has joined #lisp
z147 has quit [Remote host closed the connection]
z147 has joined #lisp
<montaropdf>
Good afternoon
<montaropdf>
I have updated the description of the lispdb format and added some examples.
shangul has quit [Remote host closed the connection]
shangul has joined #lisp
EvW1 has quit [Ping timeout: 245 seconds]
amerlyq has joined #lisp
Retropikzel has quit [Quit: Vision[0.10.3]: i've been blurred!]
jmercouris has quit [Remote host closed the connection]
georgiePorgie has joined #lisp
william1_ has joined #lisp
oxum has joined #lisp
longshi has joined #lisp
oxum has quit [Remote host closed the connection]
oxum has joined #lisp
oxum_ has quit [Ping timeout: 240 seconds]
oxum has quit [Remote host closed the connection]
krid has joined #lisp
<boeg>
is there a way to make a let binding where i can refer to the binding itself inside it? So something like `(let ((my-binding (lambda () (format "my binding: ~a" my-binding)))))` ? I can do `(let ((my-binding nil)) (setf my-binding (lambda () (format t "my-binding: ~a" my-binding))))` but if there was a way around it, it would be super cool
EvW has joined #lisp
<montaropdf>
let*
<ggole>
For lambdas, see labels
Duuqnd has quit [Ping timeout: 272 seconds]
jfb4_ has joined #lisp
jfb4 has quit [Ping timeout: 268 seconds]
glv has quit [Quit: Leaving]
<ggole>
let* makes each binding available in the successive bindings, rather than available in all of them
<montaropdf>
ggole: true, I forgot that "little" detail :/
brown121407 has quit [Read error: Connection reset by peer]
oxum has joined #lisp
Cymew has quit [Quit: Konversation terminated!]
Cymew has joined #lisp
varjag has quit [Quit: ERC (IRC client for Emacs 25.2.2)]
Cymew has quit [Ping timeout: 265 seconds]
tiwEllien has quit [Ping timeout: 268 seconds]
emacsomancer has quit [Quit: WeeChat 2.6]
emacsomancer has joined #lisp
tiwEllien has joined #lisp
georgiePorgie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
asdf_asdf_asdf has joined #lisp
aindilis has quit [Read error: Connection reset by peer]
efm_ has quit [Quit: Konversation terminated!]
efm has joined #lisp
smazga has joined #lisp
montaropdf has quit [Quit: see you soon]
adamantium has quit [Read error: Connection reset by peer]
nullman has joined #lisp
akoana has left #lisp ["Leaving"]
aindilis has joined #lisp
FreeBirdLjj has joined #lisp
galdor has quit [Quit: WeeChat 2.7]
ljavorsk__ has joined #lisp
oxum has quit [Ping timeout: 268 seconds]
ljavorsk_ has quit [Ping timeout: 240 seconds]
emacsomancer has quit [Quit: WeeChat 2.6]
emacsomancer has joined #lisp
davsebamse has quit [Ping timeout: 272 seconds]
Cymew has joined #lisp
slyrus_ has joined #lisp
longshi has quit [Ping timeout: 260 seconds]
slyrus__ has quit [Ping timeout: 260 seconds]
jmercouris has quit [Ping timeout: 268 seconds]
gko_ has quit [Ping timeout: 260 seconds]
Cymew has quit [Ping timeout: 268 seconds]
epony has joined #lisp
galdor has joined #lisp
tiwEllien has quit [Remote host closed the connection]
flamebeard has quit []
orivej has joined #lisp
jello_pudding has quit [Quit: Weechat UI Glitching, relogging]
jello_pudding has joined #lisp
tiwEllien has joined #lisp
Retropikzel has joined #lisp
epony has quit [Quit: reconf]
pjb has quit [Read error: Connection reset by peer]
ljavorsk__ has quit [Ping timeout: 268 seconds]
glick has joined #lisp
<glick>
damn lisp! so many parenthesies! why!?
<boeg>
just the right amount, or the code won't compile
<Shinmera>
can we cut this flame war off before people spend the next hour with it? Tia.
pjb has joined #lisp
msk has quit [Ping timeout: 268 seconds]
epony has joined #lisp
shka_ has quit [Quit: Konversation terminated!]
shka_ has joined #lisp
<beach>
Shinmera: Sure, no flame war.
gioyik has joined #lisp
<beach>
glick: It makes Common Lisp homoiconic which is an essential property for making it easy for programs to process code as data. And that is essential for the macro system.
<beach>
glick: But if you are an experienced and highly trained developer, you probably knew that already.
orivej has quit [Ping timeout: 265 seconds]
shka_ has quit [Ping timeout: 240 seconds]
davepdot_ has quit [Remote host closed the connection]
davepdotorg has joined #lisp
oxum has joined #lisp
<glick>
beach: im not an experienced and highly trained developer. not anymore anyway. All i know is C and python
<glick>
and the last real dev i did ws 10 years ago
<glick>
kernel stuff
Codaraxis has quit [Ping timeout: 260 seconds]
epony has quit [Quit: reconf again]
Retropikzel has quit [Quit: Vision[0.10.3]: i've been blurred!]
Retropikzel has joined #lisp
<beach>
I am sorry to hear that. Then, I suggest you go read up in order to get an answer to your question. This group is for discussions among experienced developers, so answering your question would be too long and off topic.
epony has joined #lisp
jfb4 has joined #lisp
jfb4_ has quit [Ping timeout: 265 seconds]
davepdotorg has quit [Ping timeout: 240 seconds]
pjb has quit [Read error: Connection reset by peer]
<cdegroot>
#clschool?
<beach>
cdegroot: I would have recommended that if I thought glick wanted to learn Common Lisp.
msk has joined #lisp
<cdegroot>
Fair
cosimone has joined #lisp
emys has joined #lisp
william1_ has joined #lisp
emys has quit [Ping timeout: 265 seconds]
pjb has joined #lisp
m00natic has quit [Remote host closed the connection]
varjag has joined #lisp
madrik has left #lisp ["Sleep"]
shifty has quit [Ping timeout: 268 seconds]
<glick>
lol i see beach is too "l337" to talk with a newbie
* glick
bows before supreme l337 haxor in lip beach
<glick>
lol
<glick>
relax dude
<jackdaniel>
glick: please calm down
<glick>
lip - lisp
emys has joined #lisp
oxum has quit [Ping timeout: 272 seconds]
Codaraxis has joined #lisp
emys has quit [Ping timeout: 268 seconds]
krid has quit [Ping timeout: 240 seconds]
FreeBirdLjj has quit [Remote host closed the connection]
oxum has joined #lisp
gioyik has quit [Ping timeout: 268 seconds]
ebzzry has quit [Read error: Connection reset by peer]
milanj has joined #lisp
Ven`` has joined #lisp
gioyik has joined #lisp
tiwEllien has quit [Ping timeout: 268 seconds]
oni-on-ion has quit [Ping timeout: 245 seconds]
_whitelogger has joined #lisp
oxum has quit [Ping timeout: 265 seconds]
rippa has joined #lisp
fiddlerwoaroof_ has quit [Remote host closed the connection]
gioyik has quit [Quit: WeeChat 2.7]
jonatack has joined #lisp
gioyik has joined #lisp
tiwEllien has joined #lisp
<beach>
glick: On the contrary, I am known to spend a lot of time on newbies, but I do that only as long as I estimate that it will pay off. At the moment, my estimate is that it would not be a good investment in your case. Feel free to show me that I am wrong, and I'll help.
<beach>
But not tonight. I am off to spend time with my (admittedly small) family.
emphazizer has joined #lisp
emphazizer has quit [Remote host closed the connection]
emphazizer has joined #lisp
ggole has quit [Quit: Leaving]
<glick>
beach: dont give a crap, just put me on ignore if you wish. you seem like a douchebag
emphazizer has quit [Client Quit]
<Xach>
glick: this is not a good channel to not give a crap. go away instead.
<glick>
you guys seem like you like to smell your own farts and socks
<glick>
just be chill
gnufr33d0m has joined #lisp
<glick>
jesus
<Shinmera>
the mental gymnastics on display are amazing.
glick was banned on #lisp by Xach [*!*manjaro-u@*.red-79-152-109.dynamicip.rima-tde.net]
glick was kicked from #lisp by Xach [glick]
jfb4 has quit [Ping timeout: 240 seconds]
jfb4_ has joined #lisp
shka_ has joined #lisp
davepdotorg has joined #lisp
asdf_asdf_asdf has quit [Remote host closed the connection]
davepdotorg has quit [Ping timeout: 268 seconds]
v0|d has quit [Read error: Connection reset by peer]
sauvin has quit [Read error: Connection reset by peer]
pnp has joined #lisp
<pfdietz>
(comes back and finds things have gone as expected)
msk has quit [Remote host closed the connection]
msk has joined #lisp
oxum has joined #lisp
asdf_asdf_asdf has joined #lisp
rwcom3 has joined #lisp
rwcom has quit [Ping timeout: 265 seconds]
rwcom3 is now known as rwcom
jfb4 has joined #lisp
cl-arthur has joined #lisp
jfb4_ has quit [Ping timeout: 265 seconds]
brown121408 has quit [Ping timeout: 265 seconds]
brown121407 has joined #lisp
jfb4_ has joined #lisp
jfb4 has quit [Ping timeout: 268 seconds]
cosimone has quit [Quit: Quit.]
jfb4 has joined #lisp
shka_ has quit [Ping timeout: 240 seconds]
Codaraxis has quit [Ping timeout: 260 seconds]
shka_ has joined #lisp
isoraqathedh has quit [Ping timeout: 258 seconds]
jfb4_ has quit [Ping timeout: 272 seconds]
isoraqathedh has joined #lisp
brown121407 has quit [Read error: Connection reset by peer]
hail_eris has quit [Ping timeout: 265 seconds]
brown121407 has joined #lisp
jfb4_ has joined #lisp
Codaraxis has joined #lisp
jfb4 has quit [Ping timeout: 268 seconds]
milanj has quit [Quit: This computer has gone to sleep]
whiteline has quit [Remote host closed the connection]
whiteline has joined #lisp
ralt has quit [Quit: Connection closed for inactivity]
jfb4_ has joined #lisp
jfb4 has quit [Ping timeout: 268 seconds]
cosimone has joined #lisp
oni-on-ion has joined #lisp
whiteline has quit [Remote host closed the connection]
narimiran has quit [Ping timeout: 240 seconds]
xantoz has quit [Ping timeout: 268 seconds]
acolarh has quit [Ping timeout: 268 seconds]
hiroaki has quit [Ping timeout: 268 seconds]
DGASAU has quit [Ping timeout: 268 seconds]
Codaraxis has quit [Ping timeout: 268 seconds]
xantoz has joined #lisp
whiteline has joined #lisp
hiroaki has joined #lisp
acolarh has joined #lisp
random-nick has quit [Ping timeout: 260 seconds]
brown121407 has quit [Ping timeout: 240 seconds]
brown121407 has joined #lisp
jfb4_ has quit [Ping timeout: 260 seconds]
<pnp>
Hi all... I would like to "create" a CL function not using defun, for now i'm using a form like this: (setf (fdefinition 'ADD2) (function (lambda (x) (block ADD2 (+ x 2)))))
jfb4 has joined #lisp
<Xach>
pnp: that is an insteresting constraint - what prompts it?
whiteline has quit [Remote host closed the connection]
<pnp>
the problem is that using (symbol-function 'add2) i get #<function (lambda (x)) ...>
whiteline has joined #lisp
<pnp>
while when i use defun i get the symbol that names the function
slyrus__ has joined #lisp
<no-defun-allowed>
The difference in how the functions are printed is probably implementation dependent.
<Xach>
pnp: that doesn't seem likely to me! symbol-function does not normally return a symbol.
<no-defun-allowed>
SBCL uses a SB-INT:NAMED-LAMBDA (iirc) to give a function a name.
<jackdaniel>
functions doesn't have names
<Xach>
jackdaniel: that seems like an extreme position
<jackdaniel>
it is just a convenient lie told by the implementation
<Xach>
jackdaniel: and by the spec
<Xach>
I think it is too angel-pin-head-dancy to be practically useful
slyrus_ has quit [Ping timeout: 265 seconds]
<pnp>
I mean that i get back an anonymous function
<Xach>
pnp: what prompts this interesting exercise in not using defun?
<jackdaniel>
I think that it is useful because then it is easier to understand cases like this particular one
<pnp>
while if i do (symbol-function 'car) i get #<FUNCTION CAR>
<pnp>
what i have to do to have a similar behavior?
<Xach>
jackdaniel: i think it's more useful to describe it as a one-way mapping (when limiting yourself to the standard)
<Xach>
a symbol that names a function can be used to find the function, but the function does not necessarily know that name.
milanj has joined #lisp
<pnp>
so what i have to do?
<Xach>
I don't know, sorry. I'm still curious about the context.
<cl-arthur>
pnp: you can macroexpand a defun to see what other work it might be doing behind the scenes, and compare that with what you're doing.
<pnp>
i would like to have #<FUNCTION ADD2> print out in the repl
<jackdaniel>
to me it is easier to think: there are bindings between symbols and functions, like there are bindings between symbols and values
<Xach>
pnp: why?
random-nick has joined #lisp
<jackdaniel>
but I concede there is such term in a glossary, `function name' is a name of a function in a particular environment
<pnp>
yes of course
<pnp>
i've tryied (fbounfd 'add2) and i get back T
<jackdaniel>
pnp: if you really really want to have it in the printer, you may specilize print-object with eql on your function
<pnp>
ok...
random-nick has quit [Ping timeout: 272 seconds]
<cl-arthur>
pnp: Implementation dependent presentation. You can see what a defun does by invoking (macroexpand-1 '(defun add2 (x) (+ 2 x)).
<jackdaniel>
or use defgeneric, generic functions have name slots according to the spec
<cl-arthur>
pnp: For SBCL, it a defun uses SB-INT:NAMED-LAMBDA, not lambda. (And named-lambdas obviously have a name associated with them, unlike lambdas.)
<pnp>
Thank you a lot jackdaniel ... now i jackdaniel some time to read about
<pnp>
ops, sorry for the repetion... i need time. Thank you again
<jackdaniel>
I think that answering the question about the reason why you want that would be polite given you were asked about it
gnufr33d0m has quit [Quit: gnufr33d0m]
EvW1 has quit [Ping timeout: 245 seconds]
random-nick has joined #lisp
<pnp>
because i would like to have the same output
<jackdaniel>
why you don't want to use defun?
oxum has joined #lisp
<pnp>
i was trying to think about how defun was made
<cl-arthur>
macroexpand is your friend for how in-built macros are made :)