libera/#commonlisp - IRC Chatlog
Search
7:54:30
beach
Not that anybody usually decides to work on any of the things I suggest (other than myself), but I think this is an easy one that could cut the collective maintenance burden of maintainers of Common Lisp implementations.
7:59:21
pjb
beach: that's about most of https://gitlab.com/bocl/bocl/-/blob/master/sources/lisp/macros.lisp#L310
7:59:57
pjb
beach: that said some important macros have to deal with environments, and cannot be completely independent from the implementation.
8:01:49
beach
Right. I specifically wanted to distinguish those macros that do not require any particular machinery.
8:03:22
beach
There are obviously several implementation of these macros in different Common Lisp implementations, but I wanted a separate repository for them, and documentation and such.
8:04:20
beach
And I was thinking that a relative newbie looking for a project could figure out what macros are truly portable, centralize them, write documentation strings and comments, etc.
8:16:48
splittist
beach: [not volunteering] So essentially nothing from Chapters 1-4 of the Spec; some from Chapter 5 (?); all of Chapter 6; some (?) of Chapter 7; Chapter 8 (defstruct); phoe's done Chapter 9 (conditions); nothing in Chapter 10; some of Chapter 11 (?); the handful of macros in Chapters 12-21; Chapter 22 (reader) is mainly the pretty printer (?); Chapter 23 (reader - with-standard-io-syntax) ; then Chapters 24 and 25 are pretty
8:21:45
beach
I think in SICL/Cleavir we just use the usual technique for preserving source information in macro expansions.
8:33:38
lisp123
Or should we keep them short. Issue with comments is that they may not be discoverable outside of the file
8:36:10
beach
lisp123: The documentation string is meant for clients and are mainly useful on protocol functions and classes. Comments are meant for the same people who read the code.
8:36:32
beach
lisp123: And the problem with documentation strings is that they are largely noise to the person reading the code.
8:36:39
lisp123
beach: Ah, so doc strings, I should explain INPUT & OUTPUT and comments I can do whatever is helpful?
8:37:39
beach
lisp123: So, ideally the documentation strings should be long-ish, but the problem with that is precisely the noise aspect.
8:38:18
lisp123
beach: i know what you mean, for lisp coders, one can read the code and understand exactly what its doing, doc strings are just repeating oneself in another (inexact) form for that purpose
8:38:20
beach
So I tend to use (SETF DOCUMENTATION) in a separate file so as to avoid the noise. But then there is the problem of keeping them synchronized instead.
8:39:59
lisp123
beach: thanks, that's going to be very helpful. Time to seperate out docstrings and only do them for exported functions :)
8:40:41
beach
lisp123: I tend to use #.(format nil "...") for documentation strings, so that I can use ~<newline> with the @ modifier, so that subsequent lines can be indented without changing the output of DOCUMENTATION.
8:45:33
beach
I guess one could either hide the documentation string in the definition, or provide a way to access the (separate) place where the documentation string is located, in a separate buffer.
8:50:39
splittist
(actually, that question doesn't seem to make sense - why deal with files at all?)
9:05:12
beach
moon-child: That's just my default choice. If you can convince me otherwise, I am all ears.
9:05:44
jackdaniel
it's simple. you have an ascii table printed on your desk an you edit the file with a hexeditor
9:06:58
beach
None other than that editing source code in the form of text still seems to be the most common way.
9:10:42
beach
I did attempt to design a "structure editor" at some point. The idea was to have a bunch of keystrokes valid in different contexts, so that the editing experience would resemble that of a text editor, but with fewer possibilities of making mistakes. It turned out to be too complicated though. Probably because I didn't find the right data structures for it.
11:56:05
splittist
beach: I think so - or "implementation support/internals required". As a first approximation.
12:29:03
jcowan
beach: if you are interested in a simple yet capable structure editor, I recommend taking a good look at Medley Interlisp's S-EDIT
12:29:46
jcowan
it is thoroughly documented (UI and API) in pp. 247-262 of https://interlisp.org/docs/IRM.pdf, the Interlisp Reference Manual
13:16:19
lisp123
My friend of 20 years wanted to learn programming. Naturally I recommend Common Lisp, he's going to use Kotlin instead "lisp doesn't sound practical"
13:18:23
beach
It is very hard to change people with a closed mindset. Carol Dweck has done research in the area.
13:20:49
splittist
to be fair, Kotlin has an object oriented 'Hello world' and co-routines on its homepage. Oh - and a homepage.
13:21:11
_death
Naggum said that Common Lisp is the language you graduate into... most people first need to experience the misery of other languages
13:25:45
_death
then again, the reasons people want to learn programming nowadays may be more.. varied.. than they used to be
13:34:06
lisp123
_death: honestly I never felt _too_ bad in other languages. lisp was a natural move for me after getting used to generics & protocols in Swift
13:50:29
IAmRasputin
At least Kotlin is less likely to put him off programming forever than Jav*, imho
13:51:32
dim
imagine you're new to programming in 2021, what kind of basic UI would you expect? I think web site or mobile app, I don't think terminal based keyboard driven...
13:54:24
splittist
for the junior splittists, programming (or, at least, the motivating type of programming) is about making game-like things happen on a tablet or phone. (Having said which, as the least junior ages, things happening on PCs with keyboards become interesting, too.)
14:01:04
splittist
Having started with Scratch, it's now more Construct and Unity. /I/ enjoyed TIC-80 (:
14:02:48
splittist
_death: I'm sure it's insanely complicated, but if one is motivated, and no-one tells you it's complicated...
15:03:48
jcowan
God help me if I have to do professional programming on a mobile device (unless it has a proper keyboard and screen, which to me removes it from the category "mobile device")
15:18:15
dim
it's not about using the mobile as a dev environment as much as producing an app that fits the mobile, I suppose
15:18:43
dim
though I would like that it would be possible to code an app from the mobile device itself, it would make the mobile device into an actual computer
15:20:26
pve
Hi, does anyone know if there exists an extension to ASDF that would let me compile/load all lisp files in a directory in no particular order? Perhaps as a subclass of "asdf:module".. This is something I might use when doing prototyping or other less serious things (not that anything I do is very serious :)
15:21:10
Bike
if you don't specify :serial t or dependencies for a component, asdf will just do some arbitrary order
15:21:28
Bike
do you want it to generate a component from a directory for you rather than having to write it out?
15:21:48
pve
Bike: I understand, I meant I'm too lazy to go and edit the asd file every time I want to add a file :)
15:24:34
pjb
pve: something like: :components #.(mapcar (lambda (path) `(:file (pathname-name path))) (directory #P"./*.lisp"))
15:28:15
pjb
check whether *load-pathname* is bound when you do asdf:oos 'asdf:load-op or asdf:compile-op (or the new API asdf-load).
15:28:58
pjb
pve: there's also the option of writting a little lisp script to generate a plain asd file.
15:34:59
dim
I though one of the advantages of ASDF would be to avoid the Makefile/autoconf/automake/... situation ;-)
15:35:21
dim
having lisp all the way down including the build system is a very nice property, I believe
17:44:00
pve
one minor issue is that it wont detect newly added files in the directory when I reload the system, because it doesn't think that the system has changed
19:32:31
etimmons
It's not quite ready yet (requires the latest version of ASDF that just got released)
19:33:59
etimmons
You reminded me that I should make sure it detects newly added files... Can't remember if I already handled that or not