<masinter>
let me ask in a different way... what do people use common lisp for?
<beach>
Oh wow! I think there is a lot of variation.
<masinter>
yes, i just wanted a sample
semz_ has joined #commonlisp
<beach>
My impression is that many people here use it for web stuff, and yet others rely a lot on FFI. Me and a few others (but we are likely not representative) use it to write compilers, programming tools, etc.
<beach>
I do think a lot of modern Common Lisp code uses CLOS, so that would be an essential component to add.
<masinter>
there's a PCL implementation of clos but untested for 30 years
<masinter>
we got it to compile and load
<beach>
Sort of. Several existing Common Lisp implementations use some derivative of PCL, modified for their specific needs.
<moon-child>
masinter: https://portability.cl/ lists a number of popular portability libraries; probably a good starting point
<beach>
masinter: I see what you are saying. I misunderstood before.
<moon-child>
masinter: (that said I expect getting dpans support is a higher priority than implementing support for anything nonportable)
<masinter>
there's another route, which is to port the CL parts of the dev environment to work on a more modern CL
<moon-child>
that works
<moon-child>
less sexy. Maybe more practical. Probably more work
<masinter>
more work because it requires more design
s-liao has quit [Quit: Client closed]
<masinter>
and knowing current CL dev tools to know what's worth porting
<EdLangley[m]>
The interesting bits of Interlisp/Medley to me are the stuff that’s not trying to be ANSI CL
jkordani has joined #commonlisp
<masinter>
you can use medley tools to develop common lisp
<beach>
masinter: The development tools of current FLOOS implementations of Common Lisp are fairly mediocre.
<beach>
masinter: There is no real debugger, because current FLOSS implementations of Common Lisp do not allow for breakpoints. People use Emacs+SLIME for editing code, but those tools have a very limited "knowledge" of the code being edited.
<moon-child>
(hmm. One advantage of porting interlisp to cl would be better performance. I think maiko is still using reference counting and bytecode?)
<masinter>
it's even worse -- the bytecodes emulate a big-endian machine
<masinter>
but it's 3 orders of magnitude faster than it was in its hayday
<moon-child>
only 3?
<masinter>
i know, it's all the byte-swapping
<masinter>
heyday
<beach>
I think porting it to Common Lisp is the more interesting option.
<beach>
Otherwise, you will just have yet another FLOSS Common Lisp implementation to maintain.
<moon-child>
well, presumably the development environment and debugging tools are dependent on implementation-specific functionality
<moon-child>
so, maybe you compile cl->cl, or modify an existing implementation, or interpret cl from cl, but you don't get away from the problem
<masinter>
yes, spaghetti stack
lisp123 has joined #commonlisp
<masinter>
cl in cl vs. cl in il
<masinter>
i see something called trivial-cltl2
<moon-child>
iirc that implement some environment protocol specified in cltl2 that didn't make it into dpans
<masinter>
oh ok not so interesting
<moon-child>
well, it does tell you in the name that it is 'trivial' :P
<masinter>
i was there but i don't remember what happened after x3j13 closed
<lisp123>
masinter: Is there a specification on the various dev tools of InterLisp / Medley and what they do? That could help others to port some of the functionality even though it won't be 1 to 1
<masinter>
there's lots of manuals, primers, even 3 books
<masinter>
Someone uploaded a more recent reference manual
<moon-child>
I played with interlisp a bit
<lisp123>
Thanks! Will have a read. There is McCLIM, the open source GUI framework for CL, and DREI, its editor substrate. Potentially that is where work can be done on implementing some of these ideas
<moon-child>
in-built manual was nice
<moon-child>
text was small at modern dpi though :/
<moon-child>
I don't think vector fonts make much sense until there's more colour depth :P there was a decent bitmap font that was a bit bigger, though
<moon-child>
'knxt', maybe
<masinter>
bit scaling is remarkably good if you haven't tried it
<moon-child>
bit scaling = integer scaling?
<masinter>
no
<moon-child>
what is?
<masinter>
it scales the whole raster image -- just like in zoom
<moon-child>
ok--scales how? Bilinear? That makes mincemeat of bitmapped text
<masinter>
i don't know, it's built into vnc
<moon-child>
yeah looks like bilinear or similar--I don't like it
<moon-child>
makes everything look fuzzy
s-liao has joined #commonlisp
<masinter>
i know
<White_Flame>
scaling down is always handy, though
<White_Flame>
with all the proper smoothing
<White_Flame>
VNC into a 4k screen from a 1080 one etc
<masinter>
it uses graphics card shaders
raeda has quit [Quit: Leaving]
raeda has joined #commonlisp
Oladon has joined #commonlisp
<masinter>
I have a theory why VNC is better for remote maiko than X
<masinter>
with X it's always updating the remote whenever lisp "damages" the screen bitmap
<White_Flame>
yeah, there's been lots of discussion about bitmap streaming vs command streaming in #lispcafe
<masinter>
sorry i've moved offtopic here
<White_Flame>
does X11 even do any bitmap compression?
<moon-child>
i don't think so
<lisp123>
There is work being done on a web version of McCLIM, that could be useful for a remote InterLisp
s-liao has quit [Ping timeout: 256 seconds]
wyrd_ has joined #commonlisp
wyrd has quit [Ping timeout: 276 seconds]
jealousmonk has quit [Quit: ERC 5.4.1 (IRC client for GNU Emacs 27.1)]
lisp123 has quit [Remote host closed the connection]
s-liao has joined #commonlisp
mayuresh has quit [Quit: Leaving]
Jing has joined #commonlisp
lisp123 has joined #commonlisp
Rue has quit [Quit: WeeChat 3.4]
Rue has joined #commonlisp
pve has joined #commonlisp
lisp123_ has joined #commonlisp
shka has joined #commonlisp
ogamita has joined #commonlisp
lisp123 has quit [Ping timeout: 240 seconds]
cosimone has quit [Ping timeout: 250 seconds]
lisp123_ has quit [Remote host closed the connection]
lisp123 has joined #commonlisp
lisp123 has quit [Ping timeout: 256 seconds]
dre has quit [Ping timeout: 256 seconds]
<phoe>
what is the concrete behavior of *PRINT-CIRCLE* with regard to Common Lisp primitive types? circle-printing a list like (1 1 1) does not result in (#1=1 #1# #1#) on SBCL
<phoe>
this says, "Note that implementations should not use #n# notation when the Lisp reader would automatically assure sharing without it (e.g., as happens with interned symbols)."
<phoe>
is there a concrete list of such cases anywhere? fixnums would be there, I guess, so would characters and interned symbols
<moon-child>
phoe: iirc sbcl also does not use #n= for bignums
<phoe>
yes, but these are not fixnums and therefore not EQ-comparable, so an implementation can assume that 1 and 1 are the same object and therefore don't use reader labels, whereas bignums don't satisfy that
<moon-child>
fixnums are also not EQ-comparable
<phoe>
that would assume that (1 1) can be printed as (#1=1 #1#) when the implementation cannot assume fixnums are shared
<moon-child>
the definition is somewhat wishy-washy anyway. 'the printer will _endeavor_ to detect cycles' so it's fine it it doesn't succeed?
makomo has quit [Quit: WeeChat 3.3]
<phoe>
but yes, that's off-topic to my question
<phoe>
with *PRINT-CIRCLE* being true, which Lisp data types should be printed using reader labels?
<phoe>
or, in other words, in what cases would the Lisp reader "automatically assure sharing", to quote the specification?
<phoe>
oh, I see there's an errata for just that
<phoe>
beach: do you touch this topic in WSCL?
<beach>
If it looks like undefined behavior that has no particular reason to be undefined, then sure.
<phoe>
hey wait a second, why do we have two separate WSCL repositories!?
* phoe
confused
<beach>
The second one was created by scymtym so that he can apply the parser to it.
<phoe>
yes, I see
<phoe>
I'll fix this later today - thanks for the pointer!
<beach>
Sure.
<beach>
Thank you for taking the time.
<phoe>
no problem
artchad has joined #commonlisp
lisp123 has joined #commonlisp
s-liao has quit [Ping timeout: 256 seconds]
lisp123 has quit [Ping timeout: 250 seconds]
* phoe
will, for now, simply assume that interned symbols do not get the #n# treatment
pranavats has joined #commonlisp
<phoe>
and that everything else does
<moon-child>
hmm, it appears clisp _does_ use #n= for bignums
waleee has quit [Ping timeout: 240 seconds]
s-liao has joined #commonlisp
random-nick has joined #commonlisp
Lord_of_Life has quit [Ping timeout: 256 seconds]
dec0d3r has joined #commonlisp
Lord_of_Life has joined #commonlisp
igemnace has quit [Quit: WeeChat 3.4]
lisp123 has joined #commonlisp
tfeb has joined #commonlisp
tfeb has quit [Client Quit]
s-liao30 has joined #commonlisp
s-liao has quit [Ping timeout: 256 seconds]
ec has quit [Ping timeout: 276 seconds]
ec has joined #commonlisp
<lisp123>
What if common-lisp.net started a c.l.l mailing group? That would avoid the problem with the spammers?
<phoe>
there was such an idea back in the day - either a mailgroup or some sort of online forum
<White_Flame>
there is a "lisp pros" email list, very low volume
<lisp123>
White_Flame: But I won't pass the test for that :(
<lisp123>
phoe: There's still some activity in c.l.l, so if we just tell everyone to subscribe to the mailgroup as "c.l.l 2022 and beyond", it could work. Online forum would be too much work imo
<lisp123>
and there's reddit for that to a large degree
<phoe>
lisp123: sounds like some sort of a plan; you could ask #common-lisp.net for opinion too
artchad has quit [Read error: Connection reset by peer]
perrierjouet has quit [Ping timeout: 240 seconds]
silasfox has quit [Ping timeout: 256 seconds]
<jackdaniel>
lisp123: the problem of consensus is not a technological problem. you may tell people to move to <xxx>, but they seldom do.
<phoe>
jackdaniel: the only real way of doing that is building a Much Better Product™
<jackdaniel>
I don't share this opinion
<phoe>
and I have no idea what it would take to build something that is Much Better™ than c.l.l despite its volume of spam
ec has quit [Remote host closed the connection]
ec has joined #commonlisp
mayuresh has joined #commonlisp
<lisp123>
jackdaniel: If a few people start posting there, then others follow
<lisp123>
Reddit somehow became the default forum
<mayuresh>
hello everyone. :)
<lisp123>
But yes, it requires a group effort to get that initial traction
<phoe>
hey mayuresh
<mayuresh>
phoe: i'm your friendly neighbourhood, "kathe". :)
<phoe>
mayuresh: I know
<mayuresh>
phoe: i've recommended your book to "robert virding" (erlang/otp lead).
<mayuresh>
virding has developed "lfe" (lisp flavoured erlang).
<mayuresh>
i'm trying to get him to provide the condition system there-in. ;)
<mayuresh>
phoe: just doing my (little) bit to support you. :)
<mayuresh>
though, with a vested interest. :p
<phoe>
mayuresh: let's continue that on #lisp
<phoe>
as much as I love lfe, it's not #commonlisp so off-topic here
dlowe has joined #commonlisp
<jackdaniel>
lisp123: I could raise some objections whether reddit meets the criteria of a forum ,) I didn't say that to discourage you, I keep my fingers crossed for the mailing list - they are the most convenient /for me/
<phoe>
reddit is decent social media but is not a very good forum
<mayuresh>
phoe: i didn't want to discuss "lfe", just wanted you to know that i've helped. :)
<mayuresh>
helped you that is. :)
<mayuresh>
btw, i finally settled down with lispworks.
<phoe>
mayuresh: but I wanted to discuss lfe, and how IMO having a CL-like condition system in LFE (or Erlang) doesn't really help :D
<jackdaniel>
and, a "normal" forum would be great, but oh well, they are so out of fashion (/me ceases offtopic on his part, sorry)
<mayuresh>
phoe: you want me to see you on "lisp" channel on this network? right now?
<phoe>
mayuresh: yes
<mayuresh>
phoe: okay, switching to "lisp" in a second.
<phoe>
jackdaniel: I talked with easye about that some time ago - #common-lisp.net might be a better venue
mayuresh has left #commonlisp [#commonlisp]
<lisp123>
jackdaniel: Yup :) Also a forum would be great but knowing all of us lispers, we wouldn't do it unless it was written in CL ;)
<jackdaniel>
my impression is that the sentiment that "lispers use only cl software" is heavier than actual facts
<phoe>
^
gjvc has quit [Quit: leaving]
<phoe>
dogfooding is fine, but using software only if it's CL-based rules out a whole ton of stuff
gjvc has joined #commonlisp
<phoe>
and is pretty much pointless at least in my opinion
<dlowe>
and for what
<jackdaniel>
(some hints: most implementations have a very decent ffi, the most widespread editor is written in C, multitude of bindings to non-cl libraries, finished things usually have a web interface etc)
gjvc has quit [Client Quit]
<lisp123>
I only base that opinion on CLiki tbh, that could've easily been done in MediaWiki
silasfox has joined #commonlisp
<jackdaniel>
and the fact that most of us use some kind of a posix system (I'm 100% positive that there are some lurkers joining from an opengenera vm though!)
gjvc has joined #commonlisp
<jackdaniel>
oh, and hosting wise, even cl.net uses gitlab, not a cliki-like clone for hosting git repositories
nature has joined #commonlisp
<dlowe>
CLiki predates Mediawiki
<dlowe>
I'm sure after it was established, it was just never worth the trouble to migrate
<jackdaniel>
of course having tools that you can introspect at runtime and modify is desireable
<lisp123>
dlowe: i see, makes sense
<jackdaniel>
it is just not having such tools is not a blocker for /many-if-not-most/ common lisp programmers
<lisp123>
jackdaniel: Yeah its that idea that prevented me from launching a MediaWiki version of Cliki, even though it would look alot more moden, have functional search etc.
<lisp123>
Same thing with a forum, we could just get Xenforo or Vbulletin, but it feels bad to hardcode that in a system that is not CL
<jackdaniel>
I know that I'm repeating myself, but "moving" to some other wiki would not be a technological problem
<jackdaniel>
(also, if it works, why change it? there always will be some /more/ modern solution)
<lisp123>
Well for example, the Cookbook is hardcoded right now and requires someone pushing changes to a GitHub repository and then some sort of magical transformation into some web page
<lisp123>
If the Wiki had a bit more functionality, ideally everybody would edit it directly on the site
<lisp123>
But then the problem is, whilst MW makes it easy to add stuff, it would be harder to query / inspect it from CL. Anyways all off topic and don't want to waste any more time since it's a nonissue really
dec0d3r has quit [Quit: Leaving]
gaqwas has joined #commonlisp
silasfox has quit [Ping timeout: 240 seconds]
mayuresh has joined #commonlisp
<mayuresh>
back. :)
<mayuresh>
strange, that we in mumbai are still plagued by internetwork issues.
<mayuresh>
though i am in mumbai suburban region.
<mayuresh>
does anyone here have any idea about the lispworks editor extensibility situation?
<Xach>
mayuresh: the lisp-hug mailing list gave you an answer to that question.
<Xach>
That is also the best place for lispworks questions usually.
mayuresh has quit [Ping timeout: 240 seconds]
mgl has joined #commonlisp
cosimone has joined #commonlisp
theBlackDragon has quit [Remote host closed the connection]
mayuresh has joined #commonlisp
<mayuresh>
xach: haven't received any mail yet. will wait some more time.
<mayuresh>
xach: thanks for letting me know. :)
<mayuresh>
i really gotta go, my network is going completely bonkers.
mayuresh has quit [Client Quit]
cosimone has quit [Ping timeout: 250 seconds]
Bike has joined #commonlisp
pranavats has left #commonlisp [Error from remote client]
tyson2 has joined #commonlisp
patrice has joined #commonlisp
patrice has quit [Quit: Leaving]
mon_aaraj has joined #commonlisp
perrierjouet has joined #commonlisp
mgl has quit [Quit: Client closed]
Bike has quit [Quit: Connection closed]
Everything has joined #commonlisp
waleee has joined #commonlisp
EdLangley[m] has quit [Bad user info]
cage has joined #commonlisp
unyu has quit [Ping timeout: 240 seconds]
s-liao30 has quit [Quit: Client closed]
gaqwas has quit [Remote host closed the connection]
<semz_>
Apparently #\Formfeed is not the name for ASCII character number 12 in ECL, but #\Page works there and also in SBCL... Is there a list of character names that all implementations accept? ASCII is enough, I don't expect them to agree on Unicode names.
semz_ is now known as semz
<semz>
I could go with (code-char ascii-code) of course and (rightfully) assume that every implementation is compatible with that, but it feels silly.
silasfox has joined #commonlisp
ebrasca has joined #commonlisp
mayuresh has joined #commonlisp
<mayuresh>
hello. :)
<mayuresh>
Xach: thanks for the heads-up. waited. finally received those mails from 'hug'.
<mayuresh>
Xach: thanks for your tip. but i think i can't adjust to emacs keyboarding.
<mayuresh>
beach: are you around? or is it too late at your end?
<jackdaniel>
mayuresh: a common approach on irc that is asynchronous is to ask what you want to ask and check logs later whether the person asked responded
<mayuresh>
beach: what should i google for to understand the mnemonics for a common lisp's assembler?
<mayuresh>
jackdaniel: thanks again.
<jackdaniel>
sure
<mayuresh>
beach: do all common lisp implementations use a standard mnemonic for their assembler?
Bike has joined #commonlisp
<mayuresh>
beach: if mnemonics are standardised, what's the case across 'isa'?
<phoe>
I don't think there is one standard across all implementations, simply because some implementations don't use an assembler
<phoe>
unless you count e.g. JVM instructions as an assembly format that ABCL uses, which I guess could pass
perrierjouet has quit [Quit: WeeChat 3.4]
theBlackDragon has joined #commonlisp
<mayuresh>
beach: unix 'as' uses a somewhat standardised mnemonic that varies upto a certain degree with changes in 'isa' targets.
<phoe>
or CLISP bytecode
<beach>
mayuresh: I am here for another few hours.
<mayuresh>
beach: glad.
<jackdaniel>
phoe: "assembler mnemonics" are shortened names of opcodes, that term could be generalized for various forms of bytecode too
lisp123 has quit [Remote host closed the connection]
<beach>
I don't know much about the mnemonics used by a Common Lisp assembler. Cluster (which works only for x86 at the moment) uses the mnemonics defined by Intel and AMD.
lisp123 has joined #commonlisp
<mayuresh>
beach: thanks. i got lost trying straight-forward terms under google.
<mayuresh>
so i thought there might be some in-culture thing regarding mnemonics. sorry.
<phoe>
jackdaniel: OK, that works
<beach>
mayuresh: No need to be sorry. I think each architecture defines its own mnemonics.
artchad has joined #commonlisp
ebrasca has quit [Ping timeout: 256 seconds]
<beach>
mayuresh: In addition, GAS used its own mnemonics for some architecture, to make it resemble some older architecture as I recall. But my memory is fuzzy here.
<mayuresh>
beach: that's true. 'gas' uses an extended form of the unix 'as' mnemonics with minor changes as per 'isa' differences.
ldb has joined #commonlisp
lisp123 has quit [Ping timeout: 250 seconds]
<beach>
mayuresh: For a more "standardized" set of instructions, you probably need to go up one abstraction level. Like Cleavir has some "instructions" for common operations that are the same for all backends. Those instructions are then translated according to the backend into "assembly code".
<mayuresh>
beach: yeah. but then that would just make is ansi-c. ;)
<mayuresh>
i heard "bryan cantrill" call ansi-c a "portable assembly" language. :D
<mayuresh>
sorry for veering off-topic.
<phoe>
that's a lot of ISA talk th---oh yes
<beach>
C is way too high level for a good compiler backend. And I am not talking surface syntax here. All these instructions, including the "assembly code" are in fact represented as a graph of standard objects. Not text.
<beach>
... in Cleavir I mean.
<mayuresh>
beach: read the cleavir readme. very interesting. will dig-in once i'm ready.
<mayuresh>
beach: thanks for sharing your work.
<beach>
Pleasure.
<Bike>
llvm-ir is much "lower level" than C, but still isn't really a "portable assembler", in that translating it to actual assembly is quite nontrivial (one llvm-ir instruction could become multiple machine basic blocks, for example). lisp backends seem to go about the same way, like one sbcl virtual operation (VOP) can end up as quite a bit of machine
<Bike>
code. it's interesting. computers are diverse.
<ldb>
I guess there is still not easy way to produce llvm-ir without C++ bindings
<jackdaniel>
Bike: isn't it that llvm performs later machine-specific optimizations?
<Bike>
there is some of that yeah
ebrasca has joined #commonlisp
* phoe
works on making DRAW-CONS-TREE a bit more useful in practice
<phoe>
there's such a lot of various stuff to do when working on the recipes
<phoe>
that would be a lot of arrows in some cases
<ogamita>
True, in ASCII art, that makes for big diagrams. But once you have the algorithm you can also generate svg or whatever for more compact drawing.
<ogamita>
or we can defer to GraphViz.
amb007 has quit [Read error: Connection reset by peer]
rogersm has joined #commonlisp
<phoe>
true
jkordani has joined #commonlisp
amb007 has joined #commonlisp
mon_aaraj has quit [Ping timeout: 256 seconds]
mon_aaraj has joined #commonlisp
ssafar has joined #commonlisp
<Devon>
artchad: Is that the same as package-local-nicknames?
iamFIREcracker has quit [Ping timeout: 240 seconds]
ante_ has joined #commonlisp
iamFIREcracker has joined #commonlisp
masinter has joined #commonlisp
mon_aaraj has quit [Ping timeout: 256 seconds]
cage has quit [Quit: rcirc on GNU Emacs 27.1]
mon_aaraj has joined #commonlisp
ante_ has quit [Ping timeout: 240 seconds]
Rue has quit [Ping timeout: 240 seconds]
kevingal has joined #commonlisp
Rue has joined #commonlisp
tyson2 has joined #commonlisp
<artchad>
Devon: defpackage doesn't have :package-local-nicknames
rogersm has quit [Quit: Leaving...]
<artchad>
i'm talking about a package defined with defpackage using (defpackage #:pxyz (:local-nicknames (#:a #:alexandria) (#:bt #:bordeaux-threads)))
<jackdaniel>
ogamita: in my understanding it was something for 'common lisp recipes duo', and the original book has rather practical stuff (in contrast to pedagogical things like visualising cons) - that's why I asked
<phoe>
jackdaniel: yes, except the recipe 2-1, which is surprisingly pedagogical, does mention DRAW-CONS-TREE
<phoe>
so I decided to give it a thorough code overhaul and test it properly instead of just linking to it
<artchad>
phoe, I have completion. I just need to press tab twice
<artchad>
...
<artchad>
How did I never notice that? HOW?!
<jackdaniel>
do you mean the remark in a footnote that there is a library doing that?
<jackdaniel>
but nevermind me, I was just curious
<phoe>
jackdaniel: yes
aartaka has quit [Ping timeout: 240 seconds]
jpl01 has joined #commonlisp
<jackdaniel>
n.b if I recall correctly "gentle introduction" has an example where cons cells are drawn using the clx library
<jackdaniel>
s/cells are/tree is/
<phoe>
I also recall something that used dot/graphviz
kevingal has quit [Ping timeout: 256 seconds]
<neominimum>
Hey, phoe. Is Common Lisp Recipes the II going to be a collection of entirely new recipes or past ones brought up to date? Or a combination?
<phoe>
neominimum: all the previous recipes are going to stay, I'll just update them so they're fixed up and so that their code runs on modern CL implementations and libraries
<phoe>
and I'll add some new ones
<phoe>
the second edition is meant to supersede the first one
<phoe>
it's not part II, it's 2nd Ed
<neominimum>
Nice! Okay I see. I'll be adding it to my budding collection nevertheless.
dre has joined #commonlisp
ogamita has quit [Ping timeout: 240 seconds]
dra has quit [Quit: Leaving]
dlowe has quit [Remote host closed the connection]
dlowe has joined #commonlisp
perrierjouet has quit [Quit: WeeChat 3.4]
dlowe has quit [Remote host closed the connection]
cuz` has joined #commonlisp
attila_lendvai has quit [Ping timeout: 256 seconds]
<Bike>
your compiler probably expands out type specifiers so that it doesn't have to do a complicated expansion at runtime every time
<mfiano>
Ok, I see now. Thank you.
<Bike>
this is allowed by 3.2.2.3 semantic constraints in compiled code: "Type definitions made with deftype or defstruct in the compilation environment must retain the same definition at run time."
<mfiano>
So this breaks live compilation for me without recompiling 2 other things. Hmm
<mfiano>
s/compilation/coding/
iamFIREc1 has joined #commonlisp
iamFIREcracker has quit [Ping timeout: 256 seconds]
artchad has quit [Read error: Connection reset by peer]
<White_Flame>
mfiano: if you want types to be parameterized by runtime data, pretty sure you should be using SATISFIES
perrierjouet has joined #commonlisp
<White_Flame>
otherwise, you should treat your list as a constant
<White_Flame>
(which in the same way breaks compiled things if you redefine them)
<Shinmera>
I find to have a lot less friction with the type system in CL in general when I approach it with the idea that it is meant for optimisation, not for doing type reasoning.
<phoe>
when writing (contemporary) CL, is there *any* practical reason for using ,. over ,@?
<White_Flame>
maybe if you need/want tail sharing?
<Bike>
making sure nobody can reverse engineer your program
<phoe>
the main issue is that this tail sharing is possible but not mandated
<phoe>
CLHS 2.4.6 says, Anywhere ``,@'' may be used, the syntax ``,.'' may be used instead to indicate that it is permissible to operate destructively on the list structure produced by the form following the ``,.'' (in effect, to use nconc instead of append).
<phoe>
note "permissible" rather than "mandatory", so ,. can be implemented the same way as ,@
<phoe>
at least if I am reading this correctly
<phoe>
I'm asking because I have a backquote recipe and I have a question lingering at the back of my head, "when can/should I use ,.?"
<phoe>
and I am tempted to answer "never"
<phoe>
but that's kind of a blanket answer and I want to triple-check before I commit it
shka has quit [Ping timeout: 256 seconds]
<Bike>
er, wait a sec. on the list structure produced by the form _following_ the ,.
<masinter>
the permission isn't applied here, it is indicated
<Bike>
the list you'd want to nconc is the one before that, yeah? in (,@foo ,.bar) you don't need to mutate bar
<phoe>
Bike: note (a ,.b c) though
<Bike>
i guess
<masinter>
,@ says use append
<phoe>
so if I understand correctly, then in (a ,@b ,.c d) B must be APPENDed but C can be NCONCed
<masinter>
that's how i read it
<phoe>
as if it was a performance optimization of some sort, depending on C being fresh
<phoe>
who in real life requires performance from backquote templating though
<masinter>
CONSing was expensive because GC was expensive
<phoe>
yes - hence me using present tense rather than past
<moon-child>
hmm. If the compiler can prove that C is fresh and not aliased, then it should be able to use NCONC automatically
<phoe>
I can understand it was meaningful back when we had slower hardware and poorer GCs
<phoe>
but again, for contemporary Lisp, is there any reason for using ,.
<masinter>
no it's just confusing
<Alfr>
moon-child, proving that might turn out to be far more expensive than simply copying the list structure.