freenode/#lisp - IRC Chatlog
Search
13:01:29
pyc
In Common Lisp, the format specifier ~a is same as ~A, right? Similarly #\space is same as #\Space, right? is there any popular coding convention about which form to choose?
13:05:04
no-defun-allowed
I thought Norvig and Pitman said ~A sticks out more, but it could be anyone else.
13:06:24
pyc
no-defun-allowed: thanks for the Norvig and Pitman reference. Found https://www.cs.umd.edu/~nau/cmsc421/norvig-lisp-style.pdf Invaluable resource for a Lisp beginner like me!
13:29:24
beach
Because then you clearly indicate to the reader of your code that the package of the symbol you give is not important. Only the name.
13:30:29
p_l
CL-ASHOK: : is similarly defined as reader macro that will read the symbol as one with no value and PACKAGE set to "KEYWORD" - so every time you use :, you'll always get the same symbol from the same package
13:31:15
p_l
CL-ASHOK: #: is actually a separate reader macro, which creates uninterned symbol, so it's not a keyword
13:31:49
beach
CL-ASHOK: The @ convention is not used on IRC. Just type the nick of the person followed by : and use completion for that.
13:31:50
CL-ASHOK
so : creates keyword (which can be accessed in code), while #: implies its not going to be used anywhere else
13:32:44
beach
CL-ASHOK: It can be used elsewhere, but it means that it has no home package, so you clearly say that the package is not important.
13:32:48
p_l
#: will create a new "symbol object" every time you use it, but it won't attach it to any package
13:33:49
p_l
This is useful in various situations, for example you might want to use a symbol only for it's name value one time (used to be somewhat common in package definitions) to avoid polluting the namespace with it
13:34:40
beach
I consider the "pollution" argument as being a bit weaker. The argument that it is the most specific construct is better.
13:37:25
pyc
anyone knows what the name of the book "Let Over Lambda" means? is it a pun? if so I am not getting it.
13:38:46
beach
Also referring to the fact that LET can be seen as a special case of a compound form with a lambda expression in its CAR.
13:40:15
beach
One might think that (let ((<some-var> <some-form>)) ... <some-var>) would be the same as ((lambda (<some-var>) ... <some-var>) <some-form>) would always be equivalent.
13:42:49
beach
But they aren't when <some-var> is a lambda-list keyword. Try translating (let ((&rest 10)) (+ x 20)) to the other form.
13:42:50
CL-ASHOK
beach: "... it means that it has no home package..." --> If I use ":" then it will intern in the keyword package? Wouldn't that mean its a good thing, since a package name is like a keyword and it would not be good to have any clashes with other keywords with the same name (which may happen if its uninterned)?
13:43:37
beach
CL-ASHOK: Uninterned symbols never clash, because a new symbol is created every time.
14:04:56
nij
I guess what CL-ASHOK is concerned with is that a package should correspond to a keyword.
14:05:19
nij
But if you use #:.. it creates a different keyword everytime that corresponds to the same package.
14:17:21
gendl__
beach: nij is saying it generates a separate symbol object but with the same symbol-name, so it refers to the same package object if used with e.g. defpackage or in-package.
14:18:33
beach
I am notorious for having difficulties understanding what people say/write, unless it is very precise.
14:18:48
gendl__
he’s talking about using e.g. #:my-package in one place in code, then #:my-package again in another place.
14:19:52
gendl__
I never actually thought about that. So from a memory storage point of view, :my-package would be more space-efficient.
14:21:21
gendl__
... because these things actually get stored in fasls and in the code section of memory, right?
14:22:39
phoe
note that gensyms are GCable if used only temporarily, so even if you allocate more of them then they get cleaned by the GC
14:22:56
gendl__
I’m guessing intuitively that the difference would normally be negligible. But maybe it would be something fun to experiment around with on a rainy Sunday afternoon.
14:24:19
raeda_
pyc: I have a copy of LOL. The title refers to creating a closure: the lambda captures the let's environment
14:28:16
CL-ASHOK
gendl__: "he’s talking about using e.g. #:my-package in one place in code, then #:my-package again in another place." --> Precisely, since I would define it within (defpackage and then re-use it later in the package itself)
14:30:26
beach
CL-ASHOK: The main point is that (in-package #:my-package) is very close to (in-package "MY-PACKAGE") because IN-PACKAGE takes a string designator, so if the symbol is given, its name is used which is "MY-PACKAGE".
14:30:39
CL-ASHOK
beach and Xach: Wouldn't it be a good thing for the symbols to clash (hence interning them is good), since it forces less ambiguity when writing code? Perhaps its a question of how many programmers work on a project - a single programmer perhaps should intern his package name and a large group working together perhaps should not?
14:30:56
beach
But #:my-package looks less ugly, because you would typically use lower case when you define your package.
14:32:03
beach
CL-ASHOK: Whether you use an interned or an uninterned symbol has absolutely no effect on sharing.
14:32:42
beach
CL-ASHOK: The point here is not about semantics, but about the message you send to the person reading your code.
14:32:49
CL-ASHOK
beach: thanks, that's a good reminder. I remember reading that, but that explains it nicely
14:33:28
beach
CL-ASHOK: If you use an interned symbol, you may give the reader of your code the impression that the package of that symbol is somehow important in this context.
14:33:58
beach
CL-ASHOK: Maybe you have a tool that reads this code some other way than the compiler, and that tool requires the symbol to be in a particular package.
14:34:50
beach
CL-ASHOK: Yes, and you are telling your maintainer "by the way, it has to be the keyword symbol here, because the package is important".
14:35:37
beach
CL-ASHOK: But if you use #:my-package, you are telling the maintainer "Yes, this is a symbol, but since it has no package, I can't possibly take advantage of its package"
14:36:59
CL-ASHOK
beach: sorry to be obtuse, this I don't get "since it has no package, I can't possibly take advantage of its package" --> why would someone want to take advantage of the package?
14:37:32
beach
Maybe you have a tool (the editor?) that reads the code and requires it to be a particular package.
14:38:24
beach
"In this project of mine, all the arguments to IN-PACKAGE must be keyword symbols, because I have this tool that scans my code and extracts all those symbols"
14:40:35
beach
Programmers often forget that the compiler is frequently just one of many tools that might be reading the code.
14:40:39
CL-ASHOK
is there a search tool to find Q&A answered previously in #lisp (over the last many years)?
14:50:44
beach
Well, most of this discussion was about communication with the maintainer. The semantics of Common Lisp are much simpler than those of most languages.
15:13:44
jcowan
beach: Has anyone written either a denotational or an operational semantics for a large part of CL?
15:19:12
jcowan
Usually you do full macroexpansion and then provide the semantics of what's left. Format is another matter: arguably a different language altogether.
15:20:03
jcowan
In addition, some things like LET are treated as primitive in CL, but obviously need not be.
15:22:06
beach
Nilby: It's a tricky macro, and most implementations seem to use the (not so great) MIT LOOP.
15:23:10
Nilby
It's funny, recently looked at an old MIT LOOP and it seemed much more tractable than the current one in use.
15:45:39
lukego
jcowan: it's not a large part of CL but I've recently been digging into ACL2 and wow that's an amazing system that's very strongly Common Lisp flavored.
15:46:56
lukego
yeah I was surprised to find that it seems to be alive and humming along, always assumed it would be something archaic and dying
15:48:59
Nilby
So is sicl-loop ready such that I can load it on other implementations and put in a for-as-X clause for my pet generic sequence?
15:49:49
beach
Nilby: Yes, I think so. Xach has been using it to check for non-conforming LOOP constructs in Quicklisp projects.
15:50:25
jcowan
I admit that is awesome. (Most Schemes that have LLKs make sure they aren't identifiers by using #!key or the like.)
15:50:36
beach
Nilby: In fact, nothing bad happens to you if you just load it into SBCL. You will trip the package lock, but if you accept, then it just works it seems.
16:08:43
nij
Yeah sorry for my sloppiness in using the right terminology. I understand it creates misunderstanding when I do that.. I will be more careful.
16:14:12
dieggsy
so i much prefer quri, but it's someone else's codebase - what's the puri equivalent of quri:make-uri ?
16:17:01
pjb
nij: in that case, packages are named by strings. package operators use: - package designators, which are either a package (itself), or string designators designating a package name, or - string designators (to designate symbols whose names are also strings). String designators are either characters designating a 1-char string containing it, symbols (whose name designates string equal to it), or strings.
16:18:51
pjb
nij: because of this designator hierarchy, you can (defpackage #\A (:use "CL" cl :cl #:cl #.(find-package "CL") #| <-- !! |# ) (:export #\F "F" f :f #:f))
16:23:12
jcowan
pjb: What hair. I sketched out a runtime package system for Scheme once, and my first decision was to heave all that overboard and say that the argument to a package procedure is a package object, period.
16:26:48
pjb
jcowan: yes, but in CL, packages are used at read-time, which occurs usually at compilation-time, therefore we must be able to declare things about packages possibly before or while they are defined.
16:28:02
jcowan
That was another decision: don't attempt to integrate the package system with R[67]RS library system, which exists only at macroexpansion time.
16:29:19
jcowan
Another blocker is that there just isn't enough demand for a symbol/package system used at runtime.
16:46:43
dieggsy
josrr: you're exactly right, and now that you've said that it seems obvious heh. thanks!
16:58:28
Nilby
So I managed to make an sbcl un-killable, not even a zombie. Is there even any O/S that isn't crap?
19:30:02
nij
Hi beach! Which parts of COMMONDOC aren't you convinced yet? And, when you mean to parse dpANS, do you want the macro to stay as they are, or you don't mind if it's parsed with all macros unwinded?
19:57:17
sm2n
huh, this is kind of interesting. Apparently a researcher who was trying to make a formal model for OOP ended up reinventing generic functions a la CLOS independently via theory
19:58:56
sm2n
this was while trying to give a nicer foundation to more "traditional" class-based message-passing OOP
20:05:58
Nilby
pjb: it was for real stuck. no amount of -9 could kill it "D" status in ps. But I've given up unix and now I'm just gonna run Mezzano
20:07:45
Inline
while compiling sbcl on voidlinux, it's mostly either threads-impure.lisp or so or something relating to mutexes
20:08:25
Inline
not sure if the installed ones resolved that problem, while the git version still seems to have that problem
20:11:43
Inline
Nilby: when the exit codes are not ok maybe that's why it stalls instead of terminating cleanly
20:14:04
jcowan
pjb: even kill -9 does not work with a process holding a "short-term" lock such as a file. Normally that's okay, but if the open() is taking a long time (NFS especially, but also some Fuse file systems), you are SOL. Reboot.
20:17:06
Nilby
There was no NFS, i couldn't even connect with gdb, but it's okay, since I'm going to no only use stupid unix as a bootloader for Mezzano
20:57:11
ebrasca
Can we make a better Lisp? Why let don't hendle multiple values? Like (let ((a b (function args)))...
20:58:19
gigamonkey
ebrasca: knock yourself out. you can even build on Common Lisp. (defpackage better-lisp ...) and go to town. See if it catches on.
21:03:38
ebrasca
What if you like (let* ((a b (funtion0 args)) (c d (function1 args)) (e (+ a b c d))) body) ?
21:05:34
ebrasca
Because it complicate things. Instead of making things more easy , I am adding complexity.
21:07:21
theothornhill
I can agree on destructuring by itself though - would be nice to have something like the js syntax (It exists in macros, doesn't it)?
21:07:27
gigamonkey
Bad news: you'd be adding complexity either way. Because there will still be old implementations that only support old-style LET. Maybe if you can come up with a backwards compatible syntax for the new LET it could catch on. But the world isn't goin to suddenly throw away all old code and old implementations even if there's a "better" new thing.
21:09:41
ebrasca
gigamonkey: I think my idea is compatible with old code , old let rune the same on the new let.
21:09:47
gigamonkey
I was recently reminded of this talk I gave a decade+ ago about Lisp standardization: https://soundcloud.com/zach-beane/peter-seibel-common-lisp I'd humbly suggest that anyone who wants to make a "new, better Lisp" might want to take a listen.
21:10:58
theothornhill
Absolutely. Speaking of the definition of things in lisp - I've been looking into renewing the dpans spec, and creating a new latex version of the whole spec, with all macros removed. Any ideas for how I'd convert that afterwards to something usable in say, commondoc?
21:11:11
ebrasca
Normal let binds 1 to 1 (a 1) , new let allow you to multiple bind (a b (function0 args)).
21:12:00
theothornhill
I found a wild perl-script buried in archive.org from 1996 that expands tex-macros automatically, so it suddenly is feasible
21:13:03
theothornhill
But not really sure if that gets more maintainable than creating a parser dedicated to the dpans spec...
21:13:58
theothornhill
If I'm not mistaken it is the draft for ANSI standardization of common lisp. It is needed to use that since the hyperspec is proprietary. So if we want to improve that, we have to start from scratch
21:14:02
ebrasca
My idea is to have CL with the same overall funtionality but with less duplication and easy to learn.
21:14:03
gigamonkey
theothornhill: beware of the extremely unclear copyright ownership dragons that lurk there. not saying don't do it but beware.
21:14:52
gigamonkey
theothornhill: I don't think there is any 'from scratch' as you don't have right to start from that draft and make derived works any more than you can start from the HyperSpec.
21:14:58
theothornhill
gigamonkey: Yeah, I've heard things... It seemed to me the spec itself though was "safe" to use, considering it isn't derived from the hyperspec
21:15:26
CL-ASHOK
But CL already has a reasonably large eco system around it, I think its too much effort to reinvent the wheel
21:15:43
gigamonkey
I mean, it's copywritten by whoever wrote it. It wasn't placed into the public domain, as far as I know.
21:17:06
gigamonkey
Though don't because they seem to have lost the original postscript or whatever and what you get is like a bad photocopy.
21:17:45
gigamonkey
Seriously, you'd actually probably enjoy that talk I linked above. It's about a lot of this.
21:18:12
gigamonkey
Including some thoughts (now ten years old, of course) about how we can, nonetheless, proceed.
21:18:35
CL-ASHOK
Thanks. I wonder if it goes into the public domain eventually? It would be an interesting copyright case if derivative works would be allowed
21:20:55
theothornhill
Well, one thing I discovered while wasting time on this was that there are two prominent lispers that uses sjl as initials
21:21:02
ebrasca
saturn2: Thanks, I think I first like to make other things! ( I only have 1 or 2 things that I thing can be better )
21:22:16
gigamonkey
dude, get back to us when you have at least 100. (I kept a list when I was writing PCL and it was probably way longer than that.)
21:23:12
theothornhill
gigamonkey: you could make a parser for the dpans spec that generates a new HyperSpec for PCL2. (I saw you requested ideas for binary formats O:-) )
21:29:47
theothornhill
Some of the "simpler" attempts: https://github.com/vseloved/rutils https://github.com/cl21/cl21
21:48:19
nij
Here's beach guessing CommonDoc could be a great start: https://irclog.tymoon.eu/freenode/%23lisp?around=1619602936#1619602936
21:49:43
ebrasca
I don't like cl21, why Regular Expression. How Running external programs is going to help OS writen in CL21?
21:51:53
theothornhill
nij: nice! I found this script buried deep in the nineties - perhaps it could be of use? I've experimented a little with recreating the whole spec as one file with all macros expanded, and it can be done with that script https://hg.sr.ht/~theo/clms/browse/tme.pl?rev=tip
21:53:31
theothornhill
nij: With tme.pl and texexpander the whole spec can easily be turned into a single document
21:55:52
nij
But if gigamonkey is right, we should beware of the copyright issue of dpANS... there's a copy but I dont know. I'm a #lisp noob and a legal noob as well.
21:55:54
theothornhill
Not yet into commondoc. Only a single latex document. Was able to parse it to html using pandoc, so should be doable
21:57:22
theothornhill
Yeah. Felt like we were onto something, but now it seems a little futile. I guess it is impossible to legally copy the dpans
21:58:12
theothornhill
I didn't see one. That just means its licensed to all the authors, if I'm not mistaken. Which makes it hard, since I guess not all are easy to get hold of
21:58:33
nij
Now there's at least a copy posted online by a non-author: https://github.com/xach/dpans
22:06:00
mfiano
Some people believe it is because of its intention to be, but with no formal notice, it cannot be.
22:06:40
White_Flame
best way to find out the legal status of something is to copy it and wait for a takedown notice
22:07:34
White_Flame
the thing is, it costs money to do that. _would_ somebody bother sinking money into a real lawsuit for something like the CL spec?
22:10:00
nij`
theothornhill: with the parsed version you have, do you think it's easy to create hyperlinks?
22:11:42
nij`
theothornhill: like.. how far do you think you can turn it into a CommonDoc version, with a great Master Index :D?
22:12:14
theothornhill
nij`: That's where I'm a little unclear as to what's the best way to link. Now the expander just expands all the way to be tex primitives, and it might be better to attach links to something a little less generic. Not sure
22:12:47
theothornhill
I think we can go pretty far. My first instinct was to go to markdown or something similar
22:13:33
theothornhill
I'm working now on some ways to do it reproducible. Right now there are some manual steps to get things right
22:13:52
nij`
theothornhill - I think there are some special macros used that are intended to create links?
22:14:34
nij`
I'd say if we can parse it in CommonDoc then it'd be awesome.. something that has a programmatic structures.
22:14:38
theothornhill
Not sure. If so, I think I need to rewrite the perlscript to account for those cases, and yuck
22:16:24
jcowan
gigamonkey: I wish you could get the derivative rights to PCL back, so that other P-books could be written.
22:16:40
theothornhill
nij`: maybe. It's a pretty gnarly script. Doable, of course, but I'd rather do it in lisp than perl
22:30:53
theothornhill
nij`: I think getting some input from phoe on whats needed from the macro expander to fit in nicely with CLUS. I think I remember him speaking about the macros being hard to deal with since they are all over the place
22:37:27
gigamonkey
I mean, I still own the copyright to PCL but have licensed most publication rights to Apress.
22:38:21
gigamonkey
And a Practical O'Caml that came out after and got thoroughly, and publicly, roasted by the tech reviewer.
22:39:18
gigamonkey
In theory if Apress ever lets PCL go "out of print" all the rights revert back to me but I'm not sure what that means in a world of Print On Demand books.
22:39:44
jcowan
It talks about the right things in the right order, and we now have enough Scheme de facto standardized to make it usable, perhaps with some chapters missing
22:41:20
gigamonkey
dieggsy: I think the thing linked in this Redddit post was it but that link is dead. https://www.reddit.com/r/programming/comments/q7kh/practical_ocaml_good_idea_bad_book_by_its_tech/
22:42:10
gigamonkey
Yeah, well, it was written before P.O.D. was a big thing. I don't think it really does.
22:42:38
gigamonkey
like in the days when they actually paid, in advance to print copies that sat in inventory somewhere, it was out of print when they stopped printing new copies.
22:42:46
jcowan
https://web.archive.org/web/20120608181620/http://blog.merjis.com/2006/11/08/practical-ocaml/
22:46:33
jcowan
https://chrome.google.com/webstore/detail/wayback-machine/fpnmgdkabkmnadcjpehmlllkndpkmiak?hl=en-US
22:49:14
jcowan
gigamonkey: If you feel like doing a favor for the non-CL Lisp communities, you can certainly ask for the rights back even if you are not legally entitled to them.
22:49:34
dieggsy
huh, it might not be working for me because my stupid internet provider tries to handle not found on its own
22:59:08
gigamonkey
jcowan: Apress loves putting out derivitive works. I'm sure if someone wants to write a Practical Scheme they could talk to Apress about it. And if they really want to start from PCL I guess they'd have to do a deal with me. But I doubt Apress is just going to let go of the rights.
23:02:15
gigamonkey
Oh, found my contract "The Work shall be deemed out-of-print if it is not available for sale in reasonable quantities in normal trade channels".
23:02:33
gigamonkey
So as long as the P.O.D. folks keep doing their thing, it will never go "out of print".
23:40:12
jcowan
I also looked a little bit into the old blog and the "forgotten ~U". Scheme's format is based on combinators rather than a stringly DSL, and it supports both 2^10 and 10^3 prefix scaling.
23:55:28
gigamonkey
jcowan: link to Scheme's format that you're talking about? All the docs I can find seem to be for something lifted from CL.
23:58:07
gigamonkey
Yeah, I get the urge. On the other hand I actually think sometimes it's better to have the format be just a bunch of maximally concise line noise.
23:59:22
jcowan
Granted, you can ram all that into your head, but once you reach the limit of what cl:format does, that's it.