<dim>
I've been using drakma in the past, and dexador is on my list of things to try
<pjb>
drmeister: drakma works nicely and is easy to use.
fikka has quit [Ping timeout: 245 seconds]
marvin3 has quit [Ping timeout: 250 seconds]
marvin2 has joined #lisp
Mr-Potter has quit [Ping timeout: 250 seconds]
makomo has joined #lisp
robdog__ has joined #lisp
shifty has quit [Ping timeout: 246 seconds]
<drmeister>
Thank you.
<no-defun-allowed>
yeah, drakma is very good and very easy
robdog_ has quit [Ping timeout: 252 seconds]
<no-defun-allowed>
dexador is well documented for fukamachi's projects lol
<sjl>
drakma is great
asarch has joined #lisp
<fiddlerwoaroof>
both of them have a fairly subtle gotcha
<fiddlerwoaroof>
If you pass :want-stream t to DRAKMA:HTTP-REQUEST but don't remember to close the resulting stream, you will run out of file descriptors at some point
<fiddlerwoaroof>
And, as far as I know, drakma doesn't hold onto references to all the relevant sockets, so you have to remember to keep track of the streams manully.
<fiddlerwoaroof>
So, something like (YASON:PARSE (DRAKMA:HTTP-REQUEST *URL* :WANT-STREAM T)) will eventually crash your program
<fiddlerwoaroof>
s/crash your program/render your environment unusable/
<fiddlerwoaroof>
In dexador, the :keep-alive argument defaults to t, which can result in socket leaks
<fiddlerwoaroof>
Of the HTTP clients I've used, I like it the best
zch has joined #lisp
<fiddlerwoaroof>
But it uses promises, so you have to adapt a bit to it
<jcowan>
That's a *good* thing.
robdog_ has joined #lisp
<fiddlerwoaroof>
Not disputing that
arescorpio has joined #lisp
zch has quit [Client Quit]
lnostdal has quit [Ping timeout: 268 seconds]
<fiddlerwoaroof>
Just that, you can drop drakma in anywhere and its "just another function call", when promises show up, you have to do a bit more design work
<jcowan>
wait, are you sure you mean promises?
<fiddlerwoaroof>
I think so,
<fiddlerwoaroof>
the api is very similar, e.g., to ES6 promises
<jcowan>
oh, okay, promises = futures in this context
<fiddlerwoaroof>
Hmm, to my mind at least, a future implies a promise + a thread
<jcowan>
I am used to them being different: a future executes on its own, whereas a promise does not execute at all until forced (basically just a lambda wrapper)
<fiddlerwoaroof>
No, this is promises then
longshi has joined #lisp
<fiddlerwoaroof>
carrier uses an event loop to make the request and force the promise
robdog__ has quit [Ping timeout: 268 seconds]
<fiddlerwoaroof>
but it returns a promise to you that you attach code to.
<jcowan>
Right, both are forced, but it's a question of what they do before being forced. Promises (in the sense I mean) are laziness, futures are parallelism.
<jcowan>
(threads are a building block for either parallelism or concurrency)
<fiddlerwoaroof>
O, so you'd be talking about an http library that didn't make a request until you asked for the result?
<jcowan>
That was what confused me.
buffergn0me has quit [Remote host closed the connection]
buffergn0me has joined #lisp
lnostdal has joined #lisp
<fiddlerwoaroof>
I'm glad you're not confused anymore, but I think I am now :)
iAmDecim has joined #lisp
<iAmDecim>
hmm, i figure this is a good channel to ask. how do developers with experience tackle learning a library with little to no documentation?
lmy9900 has joined #lisp
<jcowan>
(lambda () (some-computation)) returns a promise to do some computation when it is invoked, but it just sits there until you do invoke it. Not so a future, which can run to completion before it is forced, or only run part of the way, or I suppose in a degenerate case block immediately and not run at all.
varjag has quit [Ping timeout: 268 seconds]
<jcowan>
iAmDecim: Use the REPL to try things out. Of course, the more stateful the APIs are, the less good that does
<jcowan>
Another answer is, Just write your own library instead. It's more work to try to decipher someone else's buggy pile of crap than your own.
<iAmDecim>
jcowan: lol well i mean the library seems to be fairly good...just one used by experienced people that immediately can say "AHH! this is what i've been waiting for for so long" lol. i feel left out =P
<fiddlerwoaroof>
iAmDecim: one thing that can be helpful is to look at any tests they might have
<jcowan>
The article is not directly on point, but illustrates how we get into this trap.
<jcowan>
fiddlerwoaroof: Provided they are not excessively mocked out, yes.
<iAmDecim>
fiddlerwoaroof: ah now thats a good idea and something i've never done.
<iAmDecim>
but yeah...the implementation of their functions should be right there.
<fiddlerwoaroof>
I'm not quite sure how to communicate my process, but I've generally been able to do a decent job of figuring out how to use undocumented code
<jcowan>
And, of course, read the code. If it's readable.
<fiddlerwoaroof>
And, I'm always a bit suspicious of documentation because anything that's not automatically verifiable eventually turns into a lie
<jcowan>
I was adding functionality to an existing library a month or so ago, and of course wrote a functional test for it. The library and its test sailed right through Google-class code review.
Demosthenex has quit [Ping timeout: 246 seconds]
<jcowan>
Unfortunately, I had carefully mocked out the very functionality I was supposed to be testing. The real code didn't work at all, and *nobody noticed*.
<iAmDecim>
fiddlerwoaroof: yes...thats another issue I run into.
<pjb>
And even if it's not a pile of crap, the thing is that our languages and operators are rich enough to have a lot of side effects and fine points that implies a lot of unintended consequences. Basically, the code we write is overspecifying our abstract ideas we may have about it. From here comes all the difficulties and a lot of maintenance headaches.
<fiddlerwoaroof>
jcowan: yeah, it's always a bit tricky to figure out where to mock for that sort of reason
<jcowan>
My general principle is not to, but it is important on occasion to remember to mount a scratch monkey.
<fiddlerwoaroof>
I've found that over-relieance on "unit" tests makes for working bits that don't work together
Demosthenex has joined #lisp
<pjb>
ie. not even counting explicit type declarations that add to the overspecification, when you use a list or a vector when you just need an unordered collection of objects, you're overspecifying and this will have unintended consequences, both on the correctness of the code, and its future bugs.
<jcowan>
Yes, we don't do unit tests for that reason. The functional tests take ~15 minutes to run, but the test runner makes it easy to run just a specific test.
<fiddlerwoaroof>
iAmDecim: another thing is, actively read the code: don't just read it, run experiments in the repl to check your assumptions
<pjb>
that said, I'm glad I wrote some unit test, and foremost, that I tried to debug it after I made some entirely "unreleated" changes… Found a real bug :-)
<fiddlerwoaroof>
jcowan: well, I find unit tests help a lot when I'm writing the code, especially if it's something like "take this data and turn it into this other shape"
<pjb>
Not lost the time I wrote those tests, nor the time I spent debugging that…
<fiddlerwoaroof>
because, as you add edge cases to your tests, you can prevent the introduction of regressions
<pjb>
Yep. This is the real benefit.
<iAmDecim>
fiddlerwoaroof: true...i think the problem in my case is this is a web framework and i'm learning the right order to get things to work
<no-defun-allowed>
fuzz testing time
<fiddlerwoaroof>
iAmDecim: which one?
<iAmDecim>
though i suppose thats part of the learning curve
<iAmDecim>
pedestal... it's #clojure but i like to peep in #lisp as well for general insight
* jcowan
says apodictically: if there is a "right order", the API is too stateful already. The only "right order" is to construct objects before calling accessors on them.
<fiddlerwoaroof>
iAmDecim: ok :), I can give #clojure specific advice in #lispcafe ##lisp or #clojure
<jcowan>
Some of what unit tests do is done by static typing, which is another reason $EMPLOYER doesn't use them
aindilis has quit [Read error: Connection reset by peer]
<fiddlerwoaroof>
unless you're using Idris, Coq or Agda, that's not really true
<beach>
I suppose they must be right about Java HotSpot VM, V8 JavaScript VM, and Self.
<beach>
But I am surprised that those VMs were written that way, and I am surprised that the authors seem to take it for granted that things have to be written that way.
lmy9900 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<asarch>
Is there any way to know if SBCL was compiled with threads support from the REPL?
<aeth>
probably *features*
<aeth>
checking...
<asarch>
(CLIM-DEMO:DEMODEMO) is complaining about "There is no thread support in this instance.", however, in the compilation of the SBCL binary: "Enabling threads due to --fancy."
<aeth>
asarch: probably :SB-THREAD
robdog_ has joined #lisp
<no-defun-allowed>
how should i write a method for mop:slot-value-using-class?
<aeth>
I think this means it is :SB-THREAD in *FEATURES* "Users of a Lisp built with the :sb-thread feature should also read the section about threads, Threading." http://www.sbcl.org/manual/index.html#Threading-basics
<beach>
no-defun-allowed: There is a very general rule in CLOS programming: you are not allowed to write methods that are applicable when given only standardized objects.
<aeth>
no-defun-allowed: It's very close to the minimal, and it was an all day trial-and-error process, so maybe you can learn from that and skip a day
<no-defun-allowed>
fair enough
<no-defun-allowed>
thanks
DGASAU has quit [Ping timeout: 250 seconds]
<no-defun-allowed>
aeth: how do you make a class which uses CHECKED-TYPES then? metaclasses?
<aeth>
only additions were (:metaclass checked-types) and the line ":checked-type foo" for most of the slots
<aeth>
The deletion was a lot of the docstrings that said how to use it correctly, since now it can be enforced with an assert
<aeth>
(You can't use check-type because check-type takes unquoted types... Well, you probably could with some kind of eval or a macro or whatever, but that's messier)
<beach>
no-defun-allowed: SBCL will check the types of slots if you have a sufficiently high value of the DEBUG optimize quality.
<no-defun-allowed>
i'll be back with this later, sorry
<no-defun-allowed>
thanks for the information so far though :)
<aeth>
Yes, my solution isn't the only solution. I could have written a defclass* macro that wrapped defclass to enforce a higher debug when SBCL was being used. That could have other unintended consequences, though.
<aeth>
I was using it as an example of something that's very close to the minimal MOP usage, though.
gxt has quit [Ping timeout: 252 seconds]
lnostdal has joined #lisp
gxt has joined #lisp
iAmDecim has quit [Ping timeout: 252 seconds]
<asarch>
I mean, "This is SBCL 1.4.14, an implementation of ANSI Common Lisp."
igemnace has quit [Quit: WeeChat 2.3]
asarch has quit [Quit: Leaving]
iAmDecim has joined #lisp
pierpal has quit [Quit: Poof]
pierpal has joined #lisp
_whitelogger has joined #lisp
<beach>
No, 1 is a paper I was pointed to, and 2 is a video by Gregor Kiczales.
<no-defun-allowed>
so i have some key->value mappings which represent an object loosely, and i don't want to intern those
emaczen has joined #lisp
<no-defun-allowed>
so i use a hashtable which stores those mappings, and i'd like SLOT-VALUE to look up the names of symbols in that table
Essadon has quit [Quit: Qutting]
<beach>
no-defun-allowed: It sounds like you need a new metaclass. That can be very tricky because there is a lot of functionality you then must provide.
<no-defun-allowed>
i do have a metaclass which i can create classes with but i think i'm missing some components
<beach>
no-defun-allowed: I don't think you can get away with a "cookbook" technique for that. You need to understand a large part of the MOP.
<no-defun-allowed>
afaik that method never gets called, trace prints out nothing, and inspecting the class creates a stack overflow
<no-defun-allowed>
damn.
<beach>
netfarm-instance is an instance of standard-class.
<beach>
You need a new metaclass, i.e. a subclass of standard-class.
<beach>
And then you need to instantiate that class for your instances.
<beach>
Oh, you have it. Sorry.
<beach>
Missed it.
<beach>
I am not awake yet.
<beach>
That looks like it ought to work.
<beach>
But MOP stuff is tricky.
<no-defun-allowed>
i'll try again, best be sure
<p_l>
beach: while I generally agree with what you said on #1, I'm not sure I see it in this paper, other than description of typical VM built in style of Self HotSpot compiler
<no-defun-allowed>
maybe something lingered from testing, so a new environment would be better
<beach>
p_l: You are right of course. They don't explicitly say that it has to be done this way, only that the examples they use are written that way.
<p_l>
interestingly enough, an example they call in later (PyPy) is also at least somewhat self-hosted
<beach>
p_l: Nevertheless, it is depressing to me, because I was expecting something like "This is of course not the only way to implement a programming language..."
nanoz has quit [Quit: Leaving]
<p_l>
yeah, they do mention something like that, but it's a bit lost underneath :(
pierpal has quit [Read error: Connection reset by peer]
<p_l>
in my charitable reading of it, it still looks like there's assumption of "runtime" written in C
<beach>
no-defun-allowed: There might be methods on other generic functions that you have to supply as well.
<no-defun-allowed>
i'll look into aeth's code more, there were a few more
<beach>
p_l: I haven't had the "courage" to read further. I guess I should.
Arcaelyx has quit [Ping timeout: 268 seconds]
<no-defun-allowed>
being half-awake and annoyed by internet bollocks hardly goes well
<p_l>
also arguably the languages they took for their project are... much harder to compile
<beach>
I guess that's true.
<p_l>
skimmed the paper, need to pack to visit a rather unwelcoming country, but I think the techniques could be implemented in CL to implement the same languages with greater success
<no-defun-allowed>
good news: that method does get called!
<beach>
p_l: UK? USA?
<beach>
no-defun-allowed: Great!
<p_l>
beach: USA
<no-defun-allowed>
bad news: it also really breaks clos and recurses and blows the stack!
<beach>
no-defun-allowed: I can't say I am surprised.
<beach>
no-defun-allowed: Since your metaclass is a subclass of standard-class, the rest of the machinery still does what it always does. There are very likely other generic functions that need to be specialized as well.
<p_l>
UK will probably become one on 29th March if they veto the agreemeent
<no-defun-allowed>
haha, yeah, i'll keep hacking at it
<beach>
no-defun-allowed: You might want to check Pascal Costanza's implementation of LETF (this is from memory) where the slots are represented as special variable to make it thread safe.
<no-defun-allowed>
right
<no-defun-allowed>
slime just froze up and bit the dust ):
<beach>
p_l: It already is in some ways, given that they voted this way.
Arcaelyx has joined #lisp
<no-defun-allowed>
okay now setting a value in the hashtable works and the method is called, but (slot-value instance 'foo) still doesn't pick up the "slot"
<p_l>
beach: well, yeah, the atmosphere in some places can be bad from what I hear, but so far a weekend visit to London or my alma mater does not involve forms rivalling NATO SECRET access forms
<p_l>
at least for me USA always involves a level of fear
pierpal has joined #lisp
<no-defun-allowed>
beach: would it be a bad idea to write methods on SLOT-MISSING then? that actually gets called consistently on testing
Kundry_Wag has joined #lisp
eschatologist has joined #lisp
dale has joined #lisp
Kundry_Wag has quit [Ping timeout: 250 seconds]
pierpal has quit [Read error: Connection reset by peer]
<p_l>
beach: I was wondering about dropping at MIT for a moment, but I don't think I'd get to see much of the stuff that interests me
pierpal has joined #lisp
<p_l>
maybe if I hunt down the people who keep up doing SICP as extra credit course
pierpal has quit [Read error: Connection reset by peer]
<beach>
no-defun-allowed: Sure, but I doubt that the lack of such methods is the origin of your problem.
<beach>
p_l: I don't think there is anything to see. But you might catch some people, I guess.
<beach>
p_l: I know what you mean. I will again refuse to go with my (admittedly small) family to the USA for the holidays.
<p_l>
unfortunately I'm flying for business
<p_l>
and have definitely less freedom on that than I'd like
<beach>
Yes, I can see that you don't have a choice.
Bike has quit [Quit: Lost terminal]
drewes has joined #lisp
fikka has quit [Ping timeout: 268 seconds]
xkapastel has quit [Quit: Connection closed for inactivity]
pierpal has joined #lisp
<beach>
Or, rather, I can see that the consequences of opting out would be too severe.
sz0 has quit [Quit: Connection closed for inactivity]
graphene has quit [Remote host closed the connection]
<equwal>
I agree with you, and he agrees with you.
<jackdaniel>
I scream you scream we all scream for ice cream :)
Necktwi has quit [Quit: leaving]
<equwal>
goodnight
Necktwi has joined #lisp
gurmble has joined #lisp
<no-defun-allowed>
night equwal
<no-defun-allowed>
some CL book called missing features a euphemism for a bug, does anyone know which one that is?
<beach>
equwal: I think it should be part of the job description of software developers and computer scientists to systematically mistrust the fast module, and to systematically combat the closed mindset ("performance oriented" in my essay).
grumble has quit [Ping timeout: 633 seconds]
<equwal>
I think so too. The "fast module" is what it feels like to work at McDonalds. We can't do that.
<beach>
You would be surprised how many times I have observed software developers believe the fast module, thereby creating huge amounts of work for themselves as a result of a "hunch" that is just wrong by orders of magnitude.
<Inline>
morning
<beach>
Hello Inline.
<makomo>
morning
<beach>
Hello makomo.
<makomo>
\o
<Inline>
i'm uncle for the 3rd time eheh :)
<beach>
Congratulations I guess, though you did no work for it to happen.
<Inline>
thank you
<Inline>
my sister in turkey got a boy
<Inline>
heh
dale has quit [Quit: dale]
Kundry_Wag has joined #lisp
<jackdaniel>
since programmers (and computer sciencists) work with programs on regular basis, their "fast module" may be actually great (I think it was also stated in Kahneman's book, that "fast module" proofs to be very solid when we talk about experts)
<jackdaniel>
and when these experts reason about domain of their own expertise °
<Inline>
somone said of kiczales talk yesterday, where is that, is it online ?
makomo has quit [Read error: Connection reset by peer]
Necktwi has quit [Quit: leaving]
FreeBirdLjj has quit [Remote host closed the connection]
FreeBirdLjj has joined #lisp
CrazyEddy has quit [Remote host closed the connection]
FreeBirdLjj has quit [Ping timeout: 268 seconds]
orivej has joined #lisp
Kundry_Wag has joined #lisp
random-nick has joined #lisp
Zaab1t has joined #lisp
<elderK>
,Lo all
Mr-Potter has joined #lisp
<no-defun-allowed>
hey elderK
makomo has joined #lisp
robdog_ has joined #lisp
Kundry_Wag has quit [Ping timeout: 250 seconds]
<elderK>
:)
FreeBirdLjj has joined #lisp
lmy9900 has joined #lisp
eminhi has quit [Quit: leaving]
elazul has joined #lisp
FreeBirdLjj has quit [Ping timeout: 250 seconds]
Necktwi has joined #lisp
rippa has joined #lisp
Necktwi has quit [Client Quit]
<makomo>
and again my messages didn't get through, sigh...
<makomo>
speaking of talks, another nice lisp-related video, from the guy who made cl-6502 https://vimeo.com/47364930
<makomo>
elderK: ^^^
Necktwi has joined #lisp
Necktwi has quit [Client Quit]
Necktwi has joined #lisp
McParen has joined #lisp
<elderK>
Oh, excellent.
<elderK>
Thank you makomo
<elderK>
I keep a collection of "sources" to study - cl-6502 is one of them.
<elderK>
It's nicely documented, too.
<elderK>
:) I'm still working through OOP: The CLOS Perspective.
<elderK>
Unless it's for stories - I have a real problem of starting technical books, reading half way, then moving on. It's different for references like say the Intel manuals or CLtL2 - as I refer to them over and over and over, random access almost.
<elderK>
But LiSP for instance - I've started that over and over several times.
<elderK>
I always get lost at denotational semantics chapter.
<elderK>
Maybe that will be what I read next. I'm not sure :)
<elderK>
>:) But I wanna finish OOP:TCLP.
<elderK>
Also, Happy Sunday all!
FreeBirdLjj has joined #lisp
lmy9900 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<elderK>
You know, the more I read, the more I realize the same concepts seem to be discovered again and again but each time with different names.
<elderK>
As I read this stuff about "meta-level architecture", I find myself constantly thinking of "policy-based design" in C++ template metaprogramming.
<elderK>
Although the meta-level stuff is much more general.
ggole has joined #lisp
<elderK>
This isn't the first time I've noticed such... similarities between things though.
<elderK>
I wonder how much is just a simple case of being influenced by say, Lisp or Smalltalk.
<elderK>
Or how much of it is independent rediscovery?
<fiddlerwoaroof>
I've found that a lot of things look familiar once you know lisp
<elderK>
fiddlerwoaroof: Hey!
<fiddlerwoaroof>
hey
<fiddlerwoaroof>
And the similarities aren't entirely accidental: for example, Guy Steele was part of the group that made Java
<elderK>
Still - and maybe I'm just getting jaded - I wonder how much of it is NIH and people kind of build their own version of hte SAME thing and give it a new name
zch has quit [Quit: Leaving]
Necktwi has quit [Quit: leaving]
<elderK>
I have no problem with that when things improve, refine or say, for learning.
<elderK>
But often time these days, at least in the web sphere - there seems to be a lot of churn.
Necktwi has joined #lisp
<elderK>
Granted, I am not exactly knowledgable when it comes to the "web sphere" so what I say could be absolute, total foobar.
<elderK>
:)
<elderK>
Out of curiosity - and this is aimed at many in the room: How did you like, come up to speed with CL? How long did it take you? What was your learning path? Did you spend a lot of time reading the usual texts, doing exercizes? Did you simply create some small projects and hack away, slowly getting more and more complex and more comfortable?
<elderK>
Did you have someone that showed you the ropes? I'd be interested to hear.
<elderK>
:) I find the whole "Road to Lisp" thing quite interesting :)
Necktwi has quit [Quit: leaving]
Necktwi has joined #lisp
meepdeew has quit [Remote host closed the connection]
Kundry_Wag has joined #lisp
FreeBirdLjj has joined #lisp
robotoad has quit [Quit: robotoad]
makomo has quit [Ping timeout: 268 seconds]
Kundry_Wag has quit [Ping timeout: 250 seconds]
fikka has joined #lisp
FreeBirdLjj has quit [Ping timeout: 250 seconds]
cage_ has joined #lisp
fikka has quit [Ping timeout: 246 seconds]
FreeBirdLjj has joined #lisp
<pjb>
beach: we've seen nothing yet. The first generation of programmers is retired and dying, but they were just a few. Soon, a lot more will disappear, and this will be felt direly. Given that half of the programmers are newbies with less than 5 years of experience…
<pjb>
elderK: it's independent rediscovery, given that the number of programmers double every 5 years, and not all of them have been "formally educated" far from it.
lmy9900 has joined #lisp
orivej has quit [Ping timeout: 250 seconds]
makomo has joined #lisp
<elderK>
I'm not sure formal education is a good... marker.
<elderK>
Like, I have met people without formal educations, who independently research and read into things heavily, say.
iAmDecim has quit [Ping timeout: 268 seconds]
<elderK>
And then I've met those with formal educations who have stuck only to what they were taught, never exploring further.
<elderK>
pjb: But yeah, I agree. I figure it's rediscovery, too.
<elderK>
Each community has their own spin of the ideas, too.
<elderK>
Silica sounds cool too
<jackdaniel>
formal education is not a necessity, but lack of thereof spins a considerable amount of ignorant people (and it is very easy to spot an ignorant). so even if 90% of uneducated people are not ignorants, 10% is very much visible hence the availability bias leads to a simplistic correlation: uneducated -> ignorant
<jackdaniel>
it is not to say that there are no educated proffessionals who are ignorant too
Kundry_Wag has joined #lisp
<elderK>
Aye.
<elderK>
I guess as always, it depends on the person in particular. Some people, whether they have been formally educated or not, are compelled to learn more, to dig. Driven to refine their abilities.
<elderK>
And then there are some, who seem happy to rest on what they've learned, whether it's enough or not.
<jackdaniel>
another thing is that "modern" univeristy purpose is to meet market demands. market demands now high volume of programmers who will follow directions and many universities just align lowering education standards (to have more students, and money follows a student)
<jackdaniel>
but we are getting offtopic (my fault honestly:)
<elderK>
jackdaniel: Naw, my fault :) I was rambling, after all :)
robdog_ has quit [Remote host closed the connection]
Kundry_Wag has quit [Ping timeout: 244 seconds]
shifty has joined #lisp
orivej has joined #lisp
robdog_ has joined #lisp
robdog_ has quit [Ping timeout: 252 seconds]
longshi has joined #lisp
scymtym has joined #lisp
Essadon has joined #lisp
Bike has joined #lisp
Arcaelyx_ has joined #lisp
Arcaelyx has quit [Ping timeout: 268 seconds]
nirved is now known as Guest21751
nirved has joined #lisp
Guest21751 has quit [Ping timeout: 252 seconds]
Necktwi has quit [Quit: leaving]
Kundry_Wag has joined #lisp
Kundry_Wag has quit [Ping timeout: 250 seconds]
longshi has quit [Ping timeout: 252 seconds]
varjag has joined #lisp
nanoz has joined #lisp
Necktwi has joined #lisp
shka_ has quit [Read error: Connection reset by peer]
orivej has quit [Ping timeout: 250 seconds]
xkapastel has joined #lisp
Demosthenex has quit [Ping timeout: 268 seconds]
shka_ has joined #lisp
varjag has quit [Ping timeout: 245 seconds]
Demosthenex has joined #lisp
Inline has quit [Quit: Leaving]
Inline has joined #lisp
<dim>
AdventOfCode is very fun to do in CL! (https://adventofcode.com/) — the funniest part is when you read how much effort is spent in other languages to write code that runs in an acceptable time & space where in CL usually the first crappy idea you have is good enough
<dim>
I just wrote a stupid quadratic algorithm just in case it would be ok, took 16,059 microseconds (0.016059 seconds) to run, 38,608 bytes of memory allocated, with CCL
<dim>
ahah.
Demosthenex has quit [Ping timeout: 246 seconds]
Demosthenex has joined #lisp
<Xach>
hee hee
robdog_ has joined #lisp
<tumdum>
it depends on value of "other languages" - as much as I like CL, my Go and Rust solutions are as easy to write yet always faster. If you compare CL to Ruby you might be right, but that's not surprising
* jackdaniel
would be interested in seeing dim's code and tumdum's code solving the same problem (with similar amount of work)
<shka_>
dear #lisp
<pjb>
dear shka_
<shka_>
wouldn't be a good idea for open for write to provide restart for superseeding or overwriting existing file? I supposed there is a reason why this wasn't done, but this reason eludes me.
<shka_>
can someone enlighten me please?
<pjb>
Nothing prevents you to write such an open.
<shka_>
certainly, but this wasn't my question
<_death>
there are many opportunities for nice restarts when you think about them
<pjb>
This what the :if-exists parameter is for.
<shka_>
well, yeah, i would think that :if-exists :ask would be a decent idea
<pjb>
Again, never mix I/O with functionality!
<pjb>
Implement the I/O yourself.
<pjb>
You seem to have very bad software engineering practices…
<shka_>
perhaps
<shka_>
that's why i am asking why this would be a bad idea
<pjb>
shka_: also, between the time you test and the time you get the answer, the situation may have changed. This is why it wouldn't work.
<_death>
how would it ask
<pjb>
The decision must be pre-made so it can be atomic.
<pjb>
_death: by I/O.
<shka_>
_death: offer restart
<_death>
shka: you don't need :ask to offer a restart
<shka_>
pjb: ok, this is actually very good point
<shka_>
_death: no, but it would be silly to offer such restart always as it would probably create more bugs
<pjb>
Well, the fact is indeed, that no CL function has any internal restart point specified, apart from a few such as check-type, assert, or the various C-something.
<pjb>
But no function that does something has any such internal restart point specified.
<shka_>
pjb: thanks for answer, this makes sense to me now
<pjb>
For example (ASIN 42) could provide a restart to give a valid argument (all functions could have it).
lmy9900 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<pjb>
(said otherwise, no CL function is specified to use check-type, at most, to signal a type-error, that's all).
<pjb>
(well, actually (asin 42) is complex; say (asin "phi") insteadl).
<_death>
shka: the restart would be supplied when there's an error.. so if :if-exists :error errors a restart taking a new :if-exist value could be provided
<pjb>
This doesn't prevent implementations, such as ccl, to provide such restart that said.
<shka_>
_death: yes, but my point is that restarts such like this we would leak control of internals to the user which may be harmful
<_death>
shka: you can argue that against all restarts
<shka_>
well, that's their point obviously ;-)
<_death>
shka: the point of restarts is to allow making a decision somewhere else, not to hide things from the user.. for that you can just not provide the option
yvy has joined #lisp
ggole has quit [Ping timeout: 250 seconds]
ggole has joined #lisp
<_death>
the error could include more information that gives context about the OPEN.. but yes, it may be too little context to be useful except when developing
<shka_>
or for interactive use
<_death>
there could be a ROBUST-CL that specifies much more comprehensive behavior with regards to errors
<shka_>
i would say that WSCL could be somewhat considered to be close to that goal
<_death>
nowadays its performance may be acceptable
<_death>
tumdum: do you measure "faster" including the I/O???
<jackdaniel>
thanks
cage_ has quit [Remote host closed the connection]
<tumdum>
_death: I doesn't matter, you can skip io if you want
<tumdum>
jackdaniel: I don't find them better :)
void_pointer has joined #lisp
<dim>
well it's the same approach in tumdum Go's implementation and my CL one, so I would guess it takes about the same time
<dim>
my puzzle takes about 8ms to solve in CL; then again we might have large differences in the number of iterations required to find a solution in our respective puzzles, so…
<dim>
it's not a benchmarking game ;-)
<tumdum>
'cat day2.input | time -v ./day2 2>&1 | grep "User time"' results in "User time (seconds): 0.00" ;)
<dim>
well from reading the article about Taxicab geometry on Wikipedia, it seems that a solution for AOC/2017/d3 would be to generate the coordinates of the number on thr grid and then take the sum of the absolute values of them, that's it (with e.g. 3 being at (1,1) and 21 being at (-2,-2))
<dim>
maybe I'm missing something, but it doesn't look like you need to actually traverse the spiral, only to obtain the coordinates of 1 and the number in argument
<dim>
yeah looks easy, I might have a try later, I have other things to do now ;-)
<dim>
(it always look easy until you actually do it, that's the whole idea, I know)
Kundry_Wag has joined #lisp
robdog has joined #lisp
themsay has joined #lisp
Kundry_Wag has quit [Ping timeout: 246 seconds]
longshi has joined #lisp
mingus has quit [Ping timeout: 250 seconds]
Kundry_Wag has joined #lisp
Kundry_Wag has quit [Ping timeout: 250 seconds]
FreeBirdLjj has quit [Remote host closed the connection]
fikka has joined #lisp
bsimjoo has joined #lisp
bsimjoo has quit [Client Quit]
_whitelogger has joined #lisp
fikka has quit [Ping timeout: 250 seconds]
rumbler31 has joined #lisp
dacoda has quit [Remote host closed the connection]
marvin2 has quit [Ping timeout: 246 seconds]
sindan has joined #lisp
<sindan>
I'm using slime on emacs; I wonder if it's possible to declare a function/macro with &rest, that when written on the repl does not show its signature in the minibuffer, namely &rest forms, but a custom string that better reminds me of what the function expects in reality
Necktwi has quit [Quit: leaving]
Necktwi has joined #lisp
<shka_>
sindan: not in the slime i am afraid
<flip214>
sindan: then name the &rest parameter so it makes sense? "list-of-key/value-pairs"?
<sindan>
shka_ would have been nicer than looking at the code everytime I forget, but thanks
<shka_>
sindan: maybe you can hack something in emacs but i can't help with that :(
<sindan>
but then the parameter gets a stupid name and the parameter list can be much more complex than a plist
<sindan>
shka_ uff I'm a beginner with emacs, don't have time for that now sadly
<sindan>
putting that info in a specially formatted line in the docstring and retrieving it in elisp could be a start
<ggole>
elisp itself allows arg-list formatting hints in the docstring, but I don't think slime has that
heisig has joined #lisp
vlatkoB has quit [Remote host closed the connection]
elderK has quit [Ping timeout: 250 seconds]
<sindan>
if I ever want to get to know emacs/slime that's a project. Sadly I need to resort to &rest when the combination of other param types is so awkward
<sindan>
even with allow-other-keys, combining &rest with &key can avoid parameters in key position to be keywords, but the number of parameters must be even if &key is present, which is not general enough
nanozz has joined #lisp
dacoda has joined #lisp
Kundry_Wag has joined #lisp
nanoz has quit [Ping timeout: 250 seconds]
Kundry_Wag has quit [Ping timeout: 272 seconds]
<_death>
dim: cool.. where's p2?
<dim>
I just finished p1, and I'm looking at p2, and trying to decide if I want to do it
<dim>
I'm too lazy to generalize my get-spiral-coordinates ;-)
<dim>
I was pretty happy with my shortcut and now I need to remove it
<_death>
I guess that's why there are two parts.. the second can sometimes disagree with the first one's approach and the programmer has to scramble to solve it quickly
<dim>
for the input 265149 I only had to make 258 loops
<dim>
I was happy with that, you see
<dim>
well I know how to copy paste and adjust too
<dim>
I was already contemplating that you only need to keep 2 rows of the spiral and have 5 cells to look at max at each turn
<dim>
but anyway
<dim>
it was fun doing p1 ;-)
<_death>
I think the most troublesome one in 2017 was day20
<dim>
took 87 microseconds (0.000087 seconds) to run, 49,568 bytes of memory allocated
<alandipert>
_death nice day 2! mine is quite crap in comparison. But onward and upward =)
dacoda has quit [Remote host closed the connection]
<_death>
interesting that so many solutions used letter->frequency mapping.. I didn't even get to think of it because I thought the my inefficient was sufficient ;)
bsimjoo has left #lisp [#lisp]
<alandipert>
Afterward I realized I was worrying too much about perf and it definitely interfered with my flow. Tomorrow: KISS
<_death>
follow the rule of english translation :)
nanozz has quit [Ping timeout: 250 seconds]
heisig has quit [Ping timeout: 268 seconds]
scymtym has quit [Ping timeout: 268 seconds]
Kundry_Wag has joined #lisp
graphene has quit [Remote host closed the connection]
Kundry_Wag has quit [Ping timeout: 250 seconds]
graphene has joined #lisp
random-nick has quit [Read error: Connection reset by peer]
random-nick has joined #lisp
fikka has joined #lisp
rumbler31 has joined #lisp
ja-barr has quit [Quit: Exitingstage left]
robdog_ has quit [Remote host closed the connection]
graphene has quit [Remote host closed the connection]
<dim>
I think I could now easily have a spiral builder that takes a thunk as a parameter and apply it to both the puzzles, but I'm not that interested into it
graphene has joined #lisp
<dim>
and 2017/d03/p2 took 334 microseconds (0.000334 seconds) to run, with 10,544 bytes of memory allocated.
<dim>
yeah well, I've added loops that might not have been unrolled by CCL
<_death>
I mean between my naive version and yours
<dim>
SBCL reports that Evaluation took: 0.000 seconds of real time 0.000152 seconds of total run time (0.000151 user, 0.000001 system) 100.00% CPU 458,782 processor cycles 32,768 bytes consed
<dim>
anyway, not a benchmarking game
<dim>
just a mind puzzle
<_death>
:)
<dim>
your 2017/d3 solution looks nicer with the generic spiral function and all, by the way
robdog__ has quit [Ping timeout: 252 seconds]
<dim>
I just was somewhat proud of my trick where I can do a single incf for a whole spiral side at a time rather than moving only one step per loop
robdog_ has joined #lisp
<dim>
that's not keeping it simple though ;-)
<_death>
yeah, it's a good idea.. but I dislike the loops with when/do/do :x
<dim>
oh I use that all the d03p1 puzzle doesn't use that, that's the second puzzle where I did it, and I think it's very badly written too
<_death>
if-do-else-do would make that clearer (different semantics, but correct in this case), if you insist on loop ;)
rumbler31 has quit [Remote host closed the connection]
ebrasca has joined #lisp
zmt00 has quit [Ping timeout: 264 seconds]
ebrasca has quit [Remote host closed the connection]
ebrasca has joined #lisp
rumbler31 has joined #lisp
fikka has quit [Ping timeout: 250 seconds]
Demosthenex has quit [Ping timeout: 268 seconds]
CEnnis91 has quit [Quit: Connection closed for inactivity]
robdog_ has joined #lisp
robdog_ has quit [Remote host closed the connection]
robdog_ has joined #lisp
Demosthenex has joined #lisp
Demosthenex has quit [Ping timeout: 268 seconds]
fikka has joined #lisp
Demosthenex has joined #lisp
robotoad has joined #lisp
cage_ has quit [Remote host closed the connection]
fikka has quit [Ping timeout: 240 seconds]
Demosthenex has quit [Ping timeout: 240 seconds]
<jcowan>
beach: As usual, the mundane world is only now catching up to what the Lisp world has had for years
heisig has joined #lisp
Demosthenex has joined #lisp
<jcowan>
(re: the ruby-truffle paper)
<jcowan>
Frankly, what you have hold of for Sicl is genuinely groundbreaking for a HLL. If I believed in software patents, and if you hadn't disclosed all over the Internet already, I'd say: patent it.
zmt01 is now known as zmt00
Demosthenex has quit [Ping timeout: 268 seconds]
nowhere_man has quit [Ping timeout: 252 seconds]
Demosthenex has joined #lisp
rumbler3_ has joined #lisp
rumbler31 has quit [Ping timeout: 250 seconds]
drewes has joined #lisp
longshi has joined #lisp
elazul has quit [Quit: leaving]
slyrus1 has quit [Remote host closed the connection]
drewes has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
rippa has quit [Quit: {#`%${%&`+'${`%&NO CARRIER]
igemnace has quit [Quit: WeeChat 2.3]
<jackdaniel>
so that nobody can work on a similar idea ever™
vlatkoB has quit [Remote host closed the connection]
<tumdum>
ever=20years ?
<Bike>
that's badsically forever
<tumdum>
nope :)
<jackdaniel>
point being made is that such patents are obstacles to getting things better (but may be a good idea to get wealthy) and I'm quite sure beach pursues better software and not a patent portfolio
<jackdaniel>
and as of 20y, it is enough to skip whole generation of people to work on something, so from a lifetime perspective it isn't "nope :)"
<no-defun-allowed>
Patents are a bad thing for everyone who isn't the patent holder.
<tumdum>
so is private property ;)
<no-defun-allowed>
Indeed it is.
rumbler3_ has quit [Remote host closed the connection]
hhdave has joined #lisp
<jackdaniel>
making false symmetery between property and idea is not very honest
<jackdaniel>
it is like saying: I have TV so you can't have *another* TV in your house
<tumdum>
just as it is false to claim that patents have no positives :)
<jackdaniel>
nobody claimed that, so I'll let you discuss it with said nobody
<Bike>
can we not do this
* tumdum
ends this discussion
hhdave has quit [Quit: hhdave]
<no-defun-allowed>
jackdaniel: private property and personal property are distinct, usually disjoint sets though
<no-defun-allowed>
and well they call it intellectual property and put property laws on ideas quits often
debsan has joined #lisp
<Bike>
hey
<no-defun-allowed>
Right, right.
Zaab1t has quit [Quit: bye bye friends]
<jcowan>
I said "if I believed in patents", which I don't. I mean that beach's idea is both original and useful, and it's not surprising that nothing like it appears in the literature
<jcowan>
of HLLs, that is, by which I don't mean C and Fortran
<jcowan>
(Actually, I believe that people who want patents and copyrights should pay heavily for them, preferably an annual fee.)
<p_l>
jcowan: a good patent system is a boon to innovation, but a certain patent system backed by significant military was designed more for stealing ideas and mercantilist blocking of foreign companies
yvy has joined #lisp
<jcowan>
Patents are monopolies, and monopolists should pay for what they are (for sound economic reasons) allowed to deprive the rest of us of, to wit, the market value of the monopolized article.
<jcowan>
(that is, the monopoly rent, not the *whole* value)
<p_l>
jcowan: patent system origins in Europe were for monopoly-breaking by putting incentiving people to use patents rather than keeping things secret
<p_l>
because a proper patent should have all the details necessary to reproduce the invention patented + a reasonable time limit
<heisig>
May I remind people that patents are not directly related to Common Lisp :)
<p_l>
true :D
<heisig>
But it is great to hear that other people are also excited about SICL.
* jcowan
moves patent discussion to #lispcafe
<p_l>
beach: what was the "fast module"? I looked at scrollback but I'm missing some context and it seems interesting
<no-defun-allowed>
p_l: I think it’s not taking time to consider better solutions and going with whatever comes to mind first
<shka_>
p_l: beach had essay on this i think
<shka_>
gimme a second
<jcowan>
I took it to be about eschewing general solutions from fear of inefficiency
<jcowan>
which is why beach doesn't like defstruct very much
<p_l>
ehhh
<p_l>
my more common issue in code is code that is too generic
* jcowan
nods
<shka_>
as Alan Kay once said
<shka_>
"Computers are to serve humans, not the other way around" ;-)
<jcowan>
When I raised the idea of generic functions based on general (pure) predicates, he immediately raised the efficiency argument.
<jcowan>
In truth, people prefer and find intuitive, flexible, and efficient, what they are used to
<p_l>
as in, code that is too generic for the scope of the problem, causing increased complexity and thus loss of *human* performance in dealing with it
<jcowan>
Exactly
<no-defun-allowed>
Sorry, I was thinking of a different essay.
<shka_>
as it turns out beach has no essay on this topic
<p_l>
In general, my memory seems to recall mostly one somewhat common use case for defstruct in normal code (not implementation-code)
hhdave has joined #lisp
<p_l>
i.e. implementing ZetaLisp-style DEFRESOURCE
<p_l>
(object pools, essentially)
fikka has joined #lisp
random-nick has joined #lisp
shka_ has quit [Ping timeout: 246 seconds]
marusich has joined #lisp
heisig has quit [Quit: Leaving]
hhdave_ has joined #lisp
hhdave has quit [Ping timeout: 246 seconds]
hhdave_ is now known as hhdave
rumbler31 has joined #lisp
moei has quit [Quit: Leaving...]
gxt has joined #lisp
yvy has quit [Read error: Connection reset by peer]
actuallybatman has joined #lisp
angavrilov has quit [Remote host closed the connection]
anewuser has joined #lisp
longshi has quit [Quit: WeeChat 2.3]
nowhere_man has joined #lisp
gxt has quit [Ping timeout: 252 seconds]
gxt has joined #lisp
nowhere_man has quit [Ping timeout: 252 seconds]
nirved is now known as Guest33241
nirved has joined #lisp
Guest33241 has quit [Ping timeout: 252 seconds]
debsan has quit [Ping timeout: 245 seconds]
random-nick has quit [Read error: Connection reset by peer]
aindilis has joined #lisp
CEnnis91 has joined #lisp
rumbler31 has quit [Remote host closed the connection]
nowhere_man has joined #lisp
<fiddlerwoaroof>
p_l: I like (defstruct (point :type vector) x y)
<fiddlerwoaroof>
It's a quick way of generating functions like point-x point-y when you're using vectors to represent data.
<aeth>
fiddlerwoaroof: I'd much rather generate them separately because in practice you don't want 2D, you want 2D, 3D, and 4D when talking about points
<fiddlerwoaroof>
depends on the situation
<aeth>
Well, a general purpose graphical program will wind up working with all 3 because of how the various APIs work.
<fiddlerwoaroof>
I'm generally not dealing with these sort of things in a context where it makes sense for me to go fully generally
<fiddlerwoaroof>
and, this is just an example
<fiddlerwoaroof>
:type vector is a useful way to get better ways of accessing vectors than just (elt some-vector 4)
<aeth>
It's not as useful as it could be because it doesn't give you the type definition, which a regular defstruct gives you.
<aeth>
I use that to make my own constructor and type definition.
<fiddlerwoaroof>
I guess so, if I wanted a type I would generally use defclas, though
<aeth>
Never use defclass for points!
<fiddlerwoaroof>
I don't write game engines, so the performance doesn't matter too much to me
<aeth>
It's more about how you process it
<aeth>
A vector gives you a lot of options, e.g. I often find that it's most convenient to split them into multiple values.
<aeth>
A simple inline function that does this: (values (aref array 0) (aref array 1) ...)
<fiddlerwoaroof>
Anyways, my use case is mostly things like dealing with CSV of a predefined format
<aeth>
If you write your own representation, you basically force someone to handle it as a unique case with with-accessors even if it's not unique.
<aeth>
(which often involves just translating it into a vector, doubling memory usage and slowing everything down)
hhdave has quit [Quit: hhdave]
<fiddlerwoaroof>
See, the way I would handle that would be to define a protocol of generic functions that are specialized on both arrays and my classes
<aeth>
You can't do that.
<fiddlerwoaroof>
And, if the user had other things thy wanted to use, they could define methods as necessary
<aeth>
You can't define a method that specializes on arrays of a certain length because that's something that's only in the type, not in the class.
<fiddlerwoaroof>
I would just specialize on array, though
<aeth>
That, along with numbers, is why type-based dispatch libraries exist.
<fiddlerwoaroof>
and signal a condition if I cared about length
<fiddlerwoaroof>
Or do some kind of typecase inside the method
<aeth>
Well, ctypecase/etypecase is how you do that sort of thing, but it will only work for functions/methods of one, or maybe two, arguments before it quickly becomes impractical.
<fiddlerwoaroof>
Anyways, I suspect that the subset of CL I use and care about is fairly different than yours :)
<fiddlerwoaroof>
And that effects how my solution to the same problem looks
rumbler31 has joined #lisp
MightyJoe has joined #lisp
<aeth>
fiddlerwoaroof: Immutable vectors would actually be a good way to handle both use cases, assuming the compiler was smart enough to reuse the old "immutable" vector instead of copying where necessary (which would be very tricky, actually, because the compilers mostly work on functions as a unit). Then the vector could be generic and specific.
<aeth>
i.e. then you could just say (immutable-vector 1f0 2f0 3f0) and the implementation would make it a single-float vector since you can't store some other type in there.
<aeth>
If you say (vector 1f0 2f0 3f0) it has to be a T vector because you could do whatever you want to it afterward
milanj has quit [Ping timeout: 250 seconds]
<slaterr>
is there an immutable vector in standard CL or some popular third party library? and immutable collections in general
<fiddlerwoaroof>
slaterr: there's fset
<aeth>
I don't think there's a popular immutability library, unfortunately.
<fiddlerwoaroof>
it's pretty nice, but a bit underdocumente
orivej has quit [Ping timeout: 250 seconds]
<pjb>
slaterr: #(a b c) is an immutable vector.
<aeth>
You'd probably want it to be done at the implementation level and handled with a portability library, like threads, if you wanted efficiency.
<fiddlerwoaroof>
Anyways, you could totally have (vector 2f0 3f0 4f0) return a specialized vector as long as you have a check on assignment
<aeth>
pjb: Incorrect. #(a b c) is a literal vector, where mutation is undefined and should not happen. However, it is not tagged as immutable, at least in SBCL, so once you cross the compilation-unit boundary it will be mutated, with undefined and undesirable results (i.e. if you set b to d, then it will be saved as d next time you start the program)
<aeth>
It can only safely be assumed as immutable within a function.
<aeth>
very easy to get burned if you rely on it in other cases!
<p_l>
also if you set safety to 0 it will happily mutate it
<aeth>
You can, however, safely treat #(a b c) and '(a b c) as immutable within a function, and should do so if that's what you want and it doesn't cross the function boundary. (compilation-unit/file is a bit trickier, but it could be safe there as well)
graphene has quit [Remote host closed the connection]
graphene has joined #lisp
terpri has quit [Remote host closed the connection]
<aeth>
Tagging literals as immutable would be a nice implementation specific extension that could eventually solve the issue, though, afaik. It wouldn't look pretty but you *can* create them in functions, e.g. `#(a b ,c)
<aeth>
The literal notation for specialized arrays is implementation specific, though, afaik
fikka has quit [Ping timeout: 246 seconds]
razzy has quit [Ping timeout: 250 seconds]
iAmDecim has joined #lisp
fikka has joined #lisp
<jcowan>
I wouldn't count on the output of backquotes being immutable: they are code, not literals.
<jcowan>
(that is "count on" even in the sense that you might count on it in a Lisp system that makes literals immutable.)
robdog has quit [Ping timeout: 268 seconds]
justinmcp has quit [Remote host closed the connection]
justinmcp has joined #lisp
justinmcp has quit [Remote host closed the connection]
varjag has quit [Quit: ERC (IRC client for Emacs 26.1)]
justinmcp has joined #lisp
kajo has joined #lisp
dddddd has quit [Read error: Connection reset by peer]
rumbler31 has quit [Remote host closed the connection]
<Bike>
well, it's immutable in that it's undefind to modify it. i guess a system could expand it into (IMMUTABLE-VECTOR 'a 'b c) or something so it's tagged even though it's constructed at runtime.
<jcowan>
Right. Things are more expensive with lists, though, as you have to tag every cons.
<slaterr>
"undefined to modify it" is a pretty low bar
<jcowan>
Or adopt the Racket solution whereby default conses *are* immutable, and you have to ask for mutability explicitly. This was done fairly recently, and remarkably few programs had to be changed.
<jcowan>
mcons, mcar, mcdr etc
<jcowan>
http://blog.racket-lang.org/2007/11/getting-rid-of-set-car-and-set-cdr.html lists only four basic cases where people used the mutability of conses in practice: for alleged efficiency with nconc and nreverse, queues (easily replaced with explicit mutable pairs), alist updating (easily changed to a functional solution), and the use of conses as a handy 2-element struct.
<jcowan>
Of course from a standards perspective it can't be done, no matter how nice it would be. Racket's implementations of standard varities have mutable pairs.
nanozz has joined #lisp
lmy9900 has joined #lisp
nanozz has quit [Ping timeout: 246 seconds]
AroPar has joined #lisp
AroPar has quit [Remote host closed the connection]