Lisp Koans 2.0 #111
Lisp Koans 2.0 #111
Conversation
DEFCONSTANT is signaling an error when lisp-unit.lisp is reloaded. The simplest fix is to change the form to DEFVAR instead.
In order to put the koans on Quicklisp, we need to ensure that the version of lisp-unit bundled with the koans does not clash with the Quicklisp-distributed version of lisp-unit. Therefore, we rename the package.
Create a MAIN function and execute it instead of having bare toplevel forms.
Comments have been adjusted to follow CLHS standards. All #||#-style comments have been replaced with semicolon ones. Superfluous newlines have been removed.
The tag-functionality was present, but completely unused. For code clarity, it is now removed.
It should be possible to infer load-time errors with backtraces alone.
|
Your packages should generally pertain to the package it's using. |
|
I also work on cl-protobufs. optional (lisp_package) = "foo";
mesasge bar {
optional integer quux = 1;
}it will create a package We've been debating the existence of cl-protobufs/ as a pre-pended thing. |
|
Well, at least for me, I consider the name |
|
Then probably qitab |
That's where package-local nicknames come in: in the scope of your package, you can nickname I'll just go with |
|
Done. What's the next step? |
|
That's a good point, but it's not in the standard :/ |
|
@Slids Neither are sockets, threads, MOP, or accessing the garbage collector. There are portability libraries for all of them, and PLNs are no exception - see https://github.com/phoe/trivial-package-local-nicknames Currently PLNs are supported by SBCL, CCL, ECL, Clasp, ABCL, LispWorks and ACL. Only CLISP is missing out, but I plan on fixing it someday. |
|
I'll go over one more time then merge :) breakfast time though
…On Sat, May 9, 2020, 1:18 PM phoe ***@***.***> wrote:
Done. What's the next step?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#111 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AD7Y3J2YYALK4RHECBWX5RLRQWF4VANCNFSM4M4XWBFQ>
.
|
|
But those have implementations everyone agrees on, for threads see
Bordeaux-thrrads
…On Sat, May 9, 2020, 1:19 PM phoe ***@***.***> wrote:
@Slids <https://github.com/Slids> Neither are sockets, threads, MOP, or
accessing the garbage collector.
Currently PLNs are supported by SBCL, CCL, ECL, Clasp, ABCL, LispWorks and
ACL. Only CLISP is missing out, but I plan on fixing it someday.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#111 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AD7Y3J3IQONS4WJLEQYJLFTRQWGDNANCNFSM4M4XWBFQ>
.
|
|
Everyone implementing package-local nicknames also implements them the same way by using the All that the portability library does is grabbing the symbols for these functions from implementation-defined packages and reexporting them. In fact, I can paste the whole code of that library here: (defpackage #:trivial-package-local-nicknames
(:use #:cl)
(:import-from
#+sbcl #:sb-ext #+ccl #:ccl #+ecl #:ext #+abcl #:ext
#+clasp #:ext #+lispworks #:hcl #+allegro #:excl
#:package-local-nicknames
#:package-locally-nicknamed-by-list
#:add-package-local-nickname
#:remove-package-local-nickname)
(:export
#:package-local-nicknames
#:package-locally-nicknamed-by-list
#:add-package-local-nickname
#:remove-package-local-nickname)) |
|
But then you could've just set that in you chosen package name instead of
having a magically pretended string attached
…On Sat, May 9, 2020, 1:29 PM phoe ***@***.***> wrote:
Everyone implementing package-local nicknames also implements them the
same way by using the :local-nicknames extension to :defpackage and four
functions: package-local-nicknames, package-locally-nicknamed-by-list,
add-package-local-nickname, and remove-package-local-nickname. I guess
that sharing the same API counts as an implementation that everyone agrees
on.
All that the portability library does is grabbing the symbols for these
functions from implementation-defined packages and reexporting them. In
fact, I can paste the whole code of that library here:
(defpackage #:trivial-package-local-nicknames
(:use #:cl)
(:import-from
#+sbcl #:sb-ext #+ccl #:ccl #+ecl #:ext #+abcl #:ext
#+clasp #:ext #+lispworks #:hcl #+allegro #:excl
#:package-local-nicknames
#:package-locally-nicknamed-by-list
#:add-package-local-nickname
#:remove-package-local-nickname)
(:export
#:package-local-nicknames
#:package-locally-nicknamed-by-list
#:add-package-local-nickname
#:remove-package-local-nickname))
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#111 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AD7Y3J7KCKGVHGONOE3RUALRQWHG5ANCNFSM4M4XWBFQ>
.
|
|
OK - we're going offtopic anyway. :) |
|
Well, that was a huge change! |
|
Thank you! |
|
Thanks a million! I'll keep an eye on the repository in case there are any bugs remaining after the change. |
|
Yea we are, but it's one of my favorite lisp topics :)
The lisp spec really should be updated... Threads should be a part of a
language now-a-days...
As for package naming, that's a personal philosophy.
…On Sat, May 9, 2020 at 1:39 PM phoe ***@***.***> wrote:
OK - we're going offtopic anyway. :)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#111 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AD7Y3J4PPYX4L4M2RW4YRFTRQWIMPANCNFSM4M4XWBFQ>
.
|
By whom? That's the biggest question for me. X3J13 has disassembled after successfully creating a standard named ANSI CL, and I don't know how many of its members would still like to do a take-two after almost thirty years. Then there's the question of adopting the new specification, which is even more of a question. |
|
That's the problem...
Doug, Stas, etc?
…On Sat, May 9, 2020, 2:08 PM phoe ***@***.***> wrote:
The lisp spec really should be updated.
By whom? That's the biggest question for me. X3J13 has disassembled after
successfully creating a standard named ANSI CL, and I don't know how many
of its members would still like to do a take-two after almost thirty years.
Then there's the question of adopting the new specification, which is even
more of a question.
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
<#111 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AD7Y3J6G43SX5CGY5OAVWVTRQWLZDANCNFSM4M4XWBFQ>
.
|
|
There's tons of work with maintaining and developing SBCL as an ANSI CL implementation that, I suppose, is going to keep them busy - I have no idea if any of them would spend the time on extra credit work of drafting, testing, discussing, debating, approving, and implementing a new language specification. Plus, I don't know if any of them want a new CL specification - the old one is surprisingly good enough for many many uses. We also have the current de facto standards established by portability libraries, which also are good enough for many use cases. |
|
Since the CLHS cannot be updated, I think a modern public domain spiritual successor to the CLHS based on dpANS3 would be the first and necessary logical step to modernizing and updating the standard. I wish I could work on this like what I did for the MOP specification, but my infrastructure is not quite there yet... |
|
Hackernews hack: post the update to hn, they love lisp posts there.
…On Sat, May 9, 2020, 3:03 PM phoe ***@***.***> wrote:
There's tons of work with maintaining and developing SBCL as an ANSI CL
implementation that, I suppose, is going to keep them busy - I have no idea
if any of them would spend the time on extra credit work of drafting,
testing, discussing, debating, approving, and implementing a new language
specification.
Plus, I don't know if any of them *want* a new CL specification - the old
one is surprisingly good enough for many many uses. We also have the
current de facto standards established by portability libraries, which also
are good enough for many use cases.
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
<#111 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AD7Y3JZIRD6IIWKOOPMZLRDRQWSJFANCNFSM4M4XWBFQ>
.
|
|
Very nice! |
|
Hey there,
I'll have a cl to you on Monday to bring this back into Google.
…On Sat, May 9, 2020 at 11:49 PM Stanley Bileschi ***@***.***> wrote:
Very nice!
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
<#111 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AD7Y3J7362TCIDSRFXUSMKDRQYP4PANCNFSM4M4XWBFQ>
.
|
bordeaux-threads doesn't have count of threads functionality.
See:
sionescu/bordeaux-threads#70
google#111
What
This PR completely overhauls the Lisp Koans in an attempt to make them better in every way the author of the PR can imagine.
How
lisp-unittest framework and gut out everything that is not required to work with the koans. A side effect is that verifying the koans should now be slightly faster.contemplate.lspinto two files:lisp-koans.lspthat defines the package and functions related to koans andcontemplate.lspwhich actually loads the code and executes the main function.cclasp-boehm-0.4.2-2536-geb74451d6-cstWhy
lisp-unitwas renamed and therefore no longer collides with the Quicklisp-providablelisp-unitsystem.What not
Quicklisp/ASDF integration will come later.
What else
The real fun stuff begins here