libera/#commonlisp - IRC Chatlog
Search
6:07:50
beach
What is supposed to happen when we click on that link? My browser seems to hang, waiting for a response.
9:53:52
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
9:54:21
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)."
9:54:55
phoe
is there a concrete list of such cases anywhere? fixnums would be there, I guess, so would characters and interned symbols
9:58:04
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
9:59:32
phoe
that would assume that (1 1) can be printed as (#1=1 #1#) when the implementation cannot assume fixnums are shared
9:59:45
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?
10:01:40
phoe
with *PRINT-CIRCLE* being true, which Lisp data types should be printed using reader labels?
10:05:55
phoe
or, in other words, in what cases would the Lisp reader "automatically assure sharing", to quote the specification?
10:08:01
beach
If it looks like undefined behavior that has no particular reason to be undefined, then sure.
10:22:14
jackdaniel
making a pull request with a finished "issue entry" seems to be the most probable answer
10:23:29
phoe
welp - I see no space for new issues in https://github.com/robert-strandh/Well-Specified-Common-Lisp though
10:39:15
phoe
ACTION will, for now, simply assume that interned symbols do not get the #n# treatment
11:33:38
lisp123
What if common-lisp.net started a c.l.l mailing group? That would avoid the problem with the spammers?
11:34:09
phoe
there was such an idea back in the day - either a mailgroup or some sort of online forum
11:35:27
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
11:37:31
phoe
lisp123: sounds like some sort of a plan; you could ask #common-lisp.net for opinion too
11:56:43
jackdaniel
lisp123: the problem of consensus is not a technological problem. you may tell people to move to <xxx>, but they seldom do.
11:58:01
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
12:10:10
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/
12:11:44
mayuresh
phoe: i didn't want to discuss "lfe", just wanted you to know that i've helped. :)
12:12:33
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
12:12:53
jackdaniel
and, a "normal" forum would be great, but oh well, they are so out of fashion (/me ceases offtopic on his part, sorry)
12:13:31
phoe
jackdaniel: I talked with easye about that some time ago - #common-lisp.net might be a better venue
12:14:18
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 ;)
12:15:47
jackdaniel
my impression is that the sentiment that "lispers use only cl software" is heavier than actual facts
12:17:06
phoe
dogfooding is fine, but using software only if it's CL-based rules out a whole ton of stuff
12:18:40
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)
12:19:26
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!)
12:20:39
jackdaniel
oh, and hosting wise, even cl.net uses gitlab, not a cliki-like clone for hosting git repositories
12:23:18
jackdaniel
of course having tools that you can introspect at runtime and modify is desireable
12:24:06
jackdaniel
it is just not having such tools is not a blocker for /many-if-not-most/ common lisp programmers
12:25:07
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.
12:25:51
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
12:25:55
jackdaniel
I know that I'm repeating myself, but "moving" to some other wiki would not be a technological problem
12:26:49
jackdaniel
(also, if it works, why change it? there always will be some /more/ modern solution)
12:27:57
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
12:28:51
lisp123
If the Wiki had a bit more functionality, ideally everybody would edit it directly on the site
12:30:20
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
12:37:39
mayuresh
does anyone here have any idea about the lispworks editor extensibility situation?
14:57:43
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.
14:58:30
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.
15:16:26
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
15:17:03
jackdaniel
mayuresh: you may want to read http://catb.org/~esr/faqs/smart-questions.html - this is very useful if you want to learn the "common sense" on irc
15:17:37
mayuresh
beach: what should i google for to understand the mnemonics for a common lisp's assembler?
15:18:41
mayuresh
beach: do all common lisp implementations use a standard mnemonic for their assembler?
15:21:32
phoe
I don't think there is one standard across all implementations, simply because some implementations don't use an assembler
15:21:50
phoe
unless you count e.g. JVM instructions as an assembly format that ABCL uses, which I guess could pass
15:22:17
mayuresh
beach: unix 'as' uses a somewhat standardised mnemonic that varies upto a certain degree with changes in 'isa' targets.
15:24:11
jackdaniel
phoe: "assembler mnemonics" are shortened names of opcodes, that term could be generalized for various forms of bytecode too
15:24:47
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.
15:27:29
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.
15:28:16
mayuresh
beach: that's true. 'gas' uses an extended form of the unix 'as' mnemonics with minor changes as per 'isa' differences.
15:30:01
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".
15:32:09
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.
15:42:22
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