freenode/#lisp - IRC Chatlog
Search
7:20:34
beach
Let me say this again: If y'all are bored, I can give you some SICL-related tasks to accomplish.
7:41:55
contrapunctus
I'd try, but I know neither compilers nor as much CL as I'd like. Instead, I'm trying to design a set of malleable programs, exploring at least CL (+ CLIM) and Smalltalk as solutions.
9:22:19
beach
Actually, I do have a task for someone who would be interested in contributing to the SICL project. The FORMAT module is one of the first modules I wrote, and it is not particularly coupled to the rest of SICL, so it could be extracted to a separate repository. There are a few directives missing, so those are additional tasks to work on.
9:22:20
beach
And the directive interpreter exists, but the directive compiler should be written at some point. The current (huge) file format.lisp should be split up into several smaller files, probably with the code for one directive in each file. And a test suite is needed, probably mostly taken from the ANSI test suite I would imagine.
9:23:59
beach
Two systems should be supplied, one for "intrinsic" use, i.e. in a system that does not already have FORMAT, and one for "extrinsic" use, i.e. for testing in a system that has FORMAT that we don't want to clobber. Each system should have an appropriate package definition.
9:24:59
beach
It would be possible for a relative newbie to take on this task, in which case, guidance will be provided.
12:38:43
phoe
;; debugger invoked on a SB-INT:SIMPLE-READER-ERROR: no dispatch function defined for #\/
12:51:25
lisp373
Hey guys, is there a way to undefine a method? I get the "attempt to add the method ... but the method and generic function differ in whether they accept" error
13:02:04
phoe
oh, right, (defgeneric foo ()) (defmethod foo (&key x)) is going to error on DEFMETHOD
13:02:38
beach
Right, but what if the generic function is reinitialized with a different argument list.
13:54:10
puchacz
I am happy with slime, but as usual - maybe I am missing something I don't even know about
13:55:47
contrapunctus
New to CL...not a fan of how the number for ABORT* changes in different situations. I'd rather have numbers for common restarts in the beginning 🤔
13:56:16
phoe
contrapunctus: multiple ABORT restarts may mean different things, that's why there's multiple
13:57:23
phoe
beach: I know you're jaded, but that comment actually brings nothing to the discussion
13:58:44
contrapunctus
I mentioned CL21, so some CL users said that the changes they want can't be made as libraries. So I suggested making a revised community standard.
13:59:27
phoe
1) someone needs to actually go and do that, and these people are either gonna be volunteers or someone finds a funding source
13:59:40
phoe
2) someone needs to actually go and have implementers adopt it, and these people are either gonna be volunteers or someone finds a funding source
14:00:13
beach
phoe: You forget that those people have to be competent in language design and compiler design.
14:02:31
phoe
but then again, we're talking about a new one whereas the old one is still heavily unmaintained and there's no good user-facing CL documentation that isn't a book or the good ol' CLHS that is not meant to be user-facing documentation
14:03:30
phoe
once we have that, we can create a separate version that is not *the* specification but is actually useful because it contains better examples and bugfixes and what not, and then implement WSCL on top of that
14:04:48
phoe
and then, only then, when we have a good and nice stable base, we can possibly think of making an unstable branch of Common Lisp that's called Uncommon Lisp or whatever that can then be a place for further language evolution and experimentation
14:05:04
contrapunctus
I figured the actual hard part would be getting people to agree on the changes.
14:05:32
phoe
it is a task so impossible that the only viable strategy is to get no one to agree and just do the changes oneself
14:05:53
phoe
that's why we have UIOP:QUIT, the only reasonably standardized and ubiquitous way of quitting a Lisp image
14:05:57
beach
contrapunctus: I don't think it will be hard to get them to agree on WSCL, because the changes suggested are already implemented in most implementations.
14:05:59
puchacz
phoe: as a matter of naming, there was/is an Uncommon Lisp library - a web thing that uses continuations in an interpreted subset of Common Lisp.... so here you go, Common Lisp extended
14:08:09
contrapunctus
beach: that's great, and I'm sure it meets the needs of at least some users if it was implemented and you were motivated to specify it. But the fact that it's already implemented means it is by definition not something that those people wanted...so there's room for more 🙂
14:08:17
beach
contrapunctus: But, since you are "new to CL", you don't know that this issue is being discussed roughly once a month or so, typically suggested by people who have absolutely no idea why Common Lisp was created the way it was, no idea what any of their suggested changes would have as consequences to the ability to compile the language, etc.
14:08:36
phoe
contrapunctus: WSCL is actually already implemented a real lot, like, implementations do common sane things in many of these cases
14:08:46
contrapunctus
beach: oh, I'm not suggesting any changes myself. It was some folks who were more experienced than me.
14:10:04
beach
contrapunctus: So the essence of my counter argument is that most people use languages on a daily basis that don't even HAVE a standard. So why do they suddenly want every feature to be standardized for Common Lisp. Why not use a library that is widely agreed upon?
14:11:03
beach
contrapunctus: Maybe it's not clear, but this issue is being discussed over and over again. All the experienced people here already know all the issues and have their ideas about them.
14:12:47
beach
I should stop. I am really not interested in participating in this discussion again today.
14:13:16
scymtym
contrapunctus: the SLIME debugger mode (sldb-mode) has keybindings for certain restarts: q - quit, a - abort, c - continue (press C-h m in the debugger buffer to see all)
14:14:25
phoe
the way forward is simple: grab your favorite Common Lisp implementation and hit it with a hammer until it behaves in this new way you'd like it to behave in
14:16:39
phoe
nowadays perhaps it's a similar situation, with threads, networking, GC/weakness, MOP, Gray streams being ubiquitous everywhere and standardized in a de-facto way via portability libraries
14:25:53
_death
many of these are immature or lacking, so we're better off without them being standardized for the moment
14:25:58
beach
phoe: A long time ago, I had plans to write a Common Lisp reference. Now I think such a thing would be better suited for a web site.
14:27:51
phoe
one thing is a modernized version of the language specification as-is without any fixes
14:28:00
phoe
another thing is a user-facing set of documentation describing the whole language with fixes to the text and examples and such
14:28:22
beach
Would you then separate the "specification" part from the "reference" part, or would it be just the reference?
14:28:54
phoe
I'd keep the two separate, because some people (most importantly, implementers) will ask the question "what does the specifiaction say?" whereas other people (most importantly, programmers) will ask "how does it work?"
14:29:54
phoe
someone suggested some system of comments "over" the original specification that can highlight the issues found with the original text
14:31:13
beach
Such a reference would need an entry for almost each operator, class, type, etc. in the specification, but the language would be much more helpful to a user.
14:31:35
beach
So one way of starting such a reference would be to solicit contributions in the form of individual entries.
14:32:23
phoe
once the original specification is wrapped into these new clothes, then contributions will be easy
14:32:40
phoe
the main pain is converting dpANS3 into some lispy format and then presenting this lispy format in some sane way.