freenode/#lisp - IRC Chatlog
Search
7:42:10
easye
Mornin' Just to confirm an obscure part of our favorite CONS: the only standard way to associate documentation with the MAKE-* constructor created by DEFSTRUCT is to use the DOCUMENTATION SETF expander?
7:44:07
phoe
easye: yes, it seeems that (setf (documentation 'make-foo 'function) "...") is the way to go
7:44:43
beach
easye: It's the way I recommend in other cases as well, since I don't think documentation belongs in the source code.
7:45:20
beach
Documentation is for the user, whereas the person reading the code presumably knows how to use it already, so documentation is noise for the maintainer.
7:45:55
beach
The practice of putting documentation in the source code seems to encourage too brief documentation strings.
7:46:17
easye
Writing as an implementation maintainer, I don't find documentation to be noise at all. I often forget things about something I wrote some time ago.
7:46:36
no-defun-allowed
Does bordeaux-threads define if a thread can release a lock that a different thread acquired? Or, to cut out the middleman, is there an easy to access implementation of a readers-writer lock?
7:46:48
beach
Like SBCL (documentation 'car 'function) => "Return the 1st object in a list." which is incomplete.
7:47:30
beach
easye: I didn't recommend eliminating the documentation. Just putting it in a different place from that of the source code.
7:47:42
easye
But regardless of whether source code should contain documentation, I would argue that ANSI CL could use some way of documenting the constructor that DEFSTRUCT makes in the same form, otherwise such additions tend to get "lost" when moving code around.
7:48:14
easye
Sometimes what you call "documentation", I might soften as "annotation" to indicate that something is better than nothing.
7:48:59
easye
Anyways, beach, it is an interesting, strong position to advocate. It does require some level of tooling to keep the source and the docs in sync as well as docstrings.
7:49:07
phoe
no-defun-allowed: https://github.com/sionescu/bordeaux-threads/blob/master/apiv1/default-implementations.lisp#L120-L122
7:49:23
phoe
"It is an error to call this unless the lock has previously been acquired (and not released) by the same thread."
7:49:43
beach
easye: Yes, and unfortunately we seem to lack good support for my position, at least at the moment.
7:54:13
TMA
beach: It sounds like a sound position to me. Multiline docstrings are bothersome in the code. Single-line ones are not informative enough.
7:54:46
cl-arthur
beach: what improvements/differences do you have in mind? (Or maybe there's some good discussion of emacs' deficiencies somewhere you can link me?)
7:55:16
beach
TMA: Definitely. I sometimes use #.(format nil "..."). That way, I can at least indent the lines correctly, using ~@ to end the preceding ones.
7:56:12
beach
Emacs doesn't really analyze the code very well, so it often can't distinguish between different roles of a symbol.
7:58:49
beach
To get a better analysis, you can invoke the compiler, but then you have to it some key sequence, like C-c C-c. It would be preferable to get feedback sooner, like for each keystroke.
7:59:53
phoe
the recent Online Lisp Meetings talk on Eclector already shows a bit of work that has been done towards that on the reader level, so before the code is read and passed to the compiler
8:00:04
beach
Emacs/SLIME can often indent code sort of OK-ish, but there is no feedback when indentation is bad. Such feedback would catch mistakes like missing parentheses or too many closing parentheses much earlier.
8:01:02
beach
phoe: Sort of. But scymtym also included sneak previews of the next level of processing.
8:01:48
beach
Unfortunately, he sometimes forgot to clearly distinguish between the different levels.
8:03:30
beach
That kind of real-time analysis is highly desirable, and Emacs is totally incapable of doing it.
8:04:53
beach
In my opinion, we still haven't figured out how to give feedback to the user, in a way that it is immediately obvious, yet still discreet.
8:06:17
easye
I thought there are facilities in contemporary Emacs that allows one to provide asynchronous messages, like flyspell does?
8:07:13
phoe
that'd likely require sending messages to swank and receiving them back for every keystroke
8:08:10
easye
I would have separate common lisp process running its analysis pass. When it has something intelligent to report, it could message Emacs. I would also rate-limit such messages to a reasonable time window.
8:09:30
phoe
I imagine that you don't need to message the Common Lisp implementation if the editor is inside the Common Lisp implementation
8:09:47
easye
My strategy would require that the process external to Emacs somehow be able to peek at the contents of a buffer without it being flushed to disk.
8:10:20
beach
easye: Still, you can't run the compiler incrementally, so you would have to feed the entire buffer contents to it for every keystroke.
8:11:06
easye
Yes, and "feeding the buffer" would probably slow down Emacs, so one would need an non-intrusive observer of some kind.
8:12:26
OlCe
beach: Why is that? This is generally fast enough, even without incremental compilation.
8:12:31
beach
OlCe: Because you would still have to run the compiler for each keystroke, and you would have to send the entire buffer contents for each keystroke.
8:13:01
OlCe
beach: Yes. FC mitigates that with options to send only X seconds after a keystroke with no other keystroke in the interval.
8:13:27
beach
You may even have to start a fresh Common Lisp image for each keystroke, since some compile-time side effect could influence the result.
8:14:12
OlCe
beach: For Emacs Lisp, I remember the Emacs process is forked. Don't remember what is done for CL.
8:14:50
beach
OlCe: What we do know is that there is a wire protocol between Emacs and a Common Lisp process.
8:14:59
OlCe
beach: Clearly, you want (in some scenarios at least) a single image running which provides context.
8:15:53
OlCe
beach: I find Slime support great in the sense that everything that is typed is xrefed to the running image.
8:17:36
OlCe
beach: Yes, and personnally I prefer that behavior. But for automatic buffer checking, obviously, I would want the definition to be installed.
8:18:36
beach
Information about the function could be available in the compilation environment, but not in the startup environment, until the user wants to migrate it.
8:19:04
OlCe
beach: But then, we have to define the scope of these definitions. For example, up to which point do we reload files (such as the current ASDF system), because some other files may depend on function FOO, in the case you provide a new definition of FOO.
8:19:25
beach
So that if you type (defun foo (x) x) and then (defun bar (y) (foo y 234)) then you get a warning about the number of arguments to foo.
8:20:22
beach
You start with the startup environment, that you then don't change. Then you define an incremental evaluation environment and an incremental compilation environment for the buffer.
8:21:15
beach
That way, the buffer will be analyzed with respect to the startup environment and the preceding code in the buffer, but the startup environment will be modified only when the user wants it to be.
8:21:54
OlCe
beach: This sounds great, at least in theory. I do not know much about how far you can manipulate environments in the current compilers.
8:27:24
beach
CLtL2 has a section on lexical environment. Nothing on first-class global environments.
8:28:58
beach
Not at all. But we also fixed the broken definition of lexical environments in CLtL2 by creating Trucler.
8:29:14
OlCe
beach: The hyperspec defines the environments you are talking about, but no mechanism to interact with them explicitly.
8:30:17
beach
OlCe: Yes, it does, and it also says that the startup environment, the evaluation environment, and the compilation environment are allowed to be one and the same in a conforming implementation.
8:31:01
beach
OlCe: And since every existing Common Lisp implementation actually have only one environment, it is pretty useless for what I want to do.
8:33:01
minion
OlCe: Cleavir: A project to create an implementation-independent compilation framework for Common Lisp. Currently Cleavir is part of SICL, but that might change in the future
8:34:36
OlCe
beach: All these are works done at Strandh's lab, aren't they? Or are some "independent"?
8:35:46
beach
Bike and karlosz are working on Cleavir. jackdaniel is working on Clostrum. heisig wrote Trucler. scymtym wrote most of Eclector.
8:36:27
OlCe
beach: So you're Robert Strandh, I presume? (Don't know if it's against IRC etiquette to ask for that.)
8:38:24
beach
OlCe: Many people here have met several times at the annual ELS, so we pretty much know who most people are.
8:39:54
OlCe
beach: I even remember reading your rant about teaching computer science at universities.
8:40:03
easye
Unfortunately, it's looking like a couple years on COVID19. And hopefully we don't get the next pandemic that fast.
8:40:48
no-defun-allowed
I'm still hoping to attend next year, though hope doesn't arrange for intercontinental travel--oh dammit. Well, in a couple more years, I won't have to schedule university around ELS.
8:43:59
OlCe
beach: I think garbage collection for example could benefit a lot from your approach of separating components.
8:44:37
OlCe
beach: This is a point I find weak in e.g., SBCL. But maybe there are ways to control it that I don't know.
8:44:58
OlCe
beach: More generally, I would like to have some Lisp with sections of code without garbage collection.
8:45:21
OlCe
beach: Built into the language. Because I can achieve some of that with alien functions.
8:48:40
beach
OlCe: The SICL specification contains a very long description of the design of the memory manager that I would like to use. But it has not been tested.
8:53:14
OlCe
beach: For several reasons. To avoid GC pauses for real-time stuff. To be able to reclaim memory right away in case I know it was used only for temporary manipulations (a problem I hit with SBCL, may be a GC bug though, SBCL doesn't notice that and refuses to free it). To be able to use Lisp embedded. To avoid (SBCL again) having to set beforehand a big memory-mapped region sized against max anticipated memory use, which still will be
8:54:32
beach
OlCe: Oh, but those are problems with the particular technique used by SBCL. Not a general problem for garbage collectors. And malloc/free is often slower than a good GC. Plus the SICL GC is planned to be parallel and concurrent, running in multiple threads.
8:56:18
OlCe
beach: The only thing is that I'm not so keen on the GPL, but anyway... It's much much better than nothing.
8:59:19
OlCe
beach: Yes, and no. People have to eat also. And the service model is great... for services, not so for developing long-term robust software.