freenode/#lisp - IRC Chatlog
Search
4:07:16
Colleen
beach: drmeister said 2 hours, 5 minutes ago: In cstify.lisp it looks like there is a redundant (cstify (cdr list)) - is that the case?
4:09:33
beach
ebrasca: You can avoid ugly docstrings in code by using #.(format nil "...") Then you can use the ~@ format directive that lets you indent the next line in the source code, but that indentation is not part of the string.
4:11:40
beach
ebrasca: I have said this before, but I'll say it again: docstrings are typically meant for the user and not for the maintainer, but they are in a place where the user does not look and the maintainer has to. Therefore they are noise in the source code. For that reason, I use (SETF DOCUMENTATION) intsead and I put the docstrings in a separate file.
4:21:43
beach
ebrasca: It is preferable to use signals other than simple errors so that client code can catch the errors by type. It is also great to provide restarts, so that client code can communicate with the library and invoke possible ways to continue.
6:07:43
beach
I doubt that you have even read the standard of the C or C++ languages. Perl and Python don't even have one.
6:09:10
beach
I get really annoyed when Common Lisp is held to a higher standard (no pun intended) than other languages. People willingly program in languages that have no standard, and that can change at the whim of a single person. But then, when they program in Common Lisp, IT HAS TO BE IN THE ANSI STANDARD, or else IT DOESN'T EXIST to them.
6:10:20
beach
asarch: By "a standard", I mean a document published by an independent organization that is not the one that provides the code for the implementation, so that the document can not change at the whim of the people delivering the code.
6:11:27
beach
asarch: Now, you obviously don't seem to know whether such a document exists for the languages that you cited, so why on earth would you require it to even exist for Common Lisp?
6:11:50
stylewarning
beach: I think in a lot of cases people simply do not understand the value of having an accessible language standard.
6:12:54
stylewarning
beach: A frequent complaint about Lisp that I hear is, "There isn't a lot of Stack Overflow posts about it!" I usually respond by saying, "Fortunately, many answers to your questions can actually be found in the freely available language standard itself."
6:12:54
asarch
Well, that's because the Perl/Python "standard" is dictated by a benevolent dictator of life, but I just was wondering. How can I read the arguments passed to a program?
6:13:06
stylewarning
Unfortunately, from there, they're expecting some truly opaque standard, like the C++ standard. :)
6:14:30
stylewarning
asarch: Arguments passed to a program is a Lisp-dependent thing. But the library that comes with ASDF, called UIOP, provides this.
6:14:38
asarch
Don't get excited, this is my first day at France and all I want is: "Excusez-moi monsieur, comment puis-je me rendre à la boulangerie?"
6:16:08
beach
asarch: I do get upset, but I have nothing against you personally. I get upset because, like I said, for some reason, people hold Common Lisp to a higher standard than other languages. And I am sure the reason is what stylewarning is saying, namely that people don't understand the value of an independent standard.
6:16:45
beach
asarch: So you should see my remarks as directed not to you personally, but to all the people who come here and complain about things that are not in the standard.
6:17:51
stylewarning
I've been toying with the idea of having a sort of de facto Common Lisp standards committee, to conservatively adopt already tried-and-true de facto standards in the form of CDR's.
6:18:56
beach
stylewarning: I have a project with similar goals. It is called WSCL (which stands for Well-Specified Common Lisp, and is pronounced like "whistle"). Have you seen it?
8:14:51
makomo
i also had a deadline until 23:59 yesterday, writing a codegen for a c-like language (given the parsing tree)
8:15:19
makomo
my teammate was supposed to do it, but he choked so i had to jump in (same thing happen in his previous exercise too)
8:16:22
makomo
what a ride it was. completely rewrote what he did (which wasn't much anyway) and managed to pull it off. in total ~9 hours of coding
8:26:20
makomo
beach: WSCL seems interesting. found a typo in the README: "and is\ndesign so that each chapter"
8:27:16
pjb
makomo: no, in a very classic way, the requirements increased tenfold as the deadline came closer.
8:28:06
pjb
makomo: it's not clear if it was "the" toy compiler, or "a" toy compiler compiling the same language.
8:29:49
pjb
there was one guy who had fun implementing a toy compiler and a toy VM on github (I had same fun at least twice on usenet). Then his teacher took that toy compiler as an example in his compilation lecture.
8:30:19
pjb
makomo: <megachombass> all is base on this guy work : https://github.com/thibaudcolas/clisp-compiler-vm
8:33:22
makomo
actually, the thing i was doing is pretty similar. the code generation was done for an imaginary processor for which a simulator exists which is used to actually run the code and test the output of the programs
8:33:31
pjb
Either he keeps the compiler which is written in CL and uses sexps as is, and he needs a lisp VM with operations such as CONS, CAR, CDR, etc. Or he rewrites his compiler to use only integers, since the current VM only deals with integers. What's more, the current VM is not a Von Neuman architecture!
8:34:02
pjb
Namely, the program stored in memory cannot be written by a program in the VM, since as said, the VM only has integers, and the programs contain sexps!
8:35:39
pjb
So, in 22 hours, and being tired, I don't think many people would be able to do it from scratch.
8:35:50
makomo
but if the compiler is supposed to compile from Lisp into VM bytecode, couldn't he just compile the compile?
8:36:05
makomo
i suppose the compiler isn't powerful enough to handle all of the lisp constructs he had used in his compiler?
8:39:49
pjb
It's funny, because we knew from the start it would be a failure… So many in the same situation…
8:54:49
makomo
mhm. especially if the person is inexperienced and doesn't know what "to do next" or anticipate problems that might come up and avoid them before they occur
10:02:06
phoe
Does CL have any kind of operator that applies FN consecutively to ARG N times and returns the last result?
10:05:30
beach
phoe: Sometimes, it is easier to understand code if it doesn't refer to some external function that has to be looked up in the documentation. Especially short snippets like this.
11:00:17
Cymew
I repeatedly tear my hair out over LOOP syntax, and smile like a fool when I get it right and it's just so clever.
11:03:50
loke
I do remember feeling confused by it the first time I used it, but these days it's second nature.
11:09:34
beach
Or perhaps I mean (loop for x = bla then (f y) for y ...) I can't remember the details.
11:11:18
makomo
actually there were 2 but extermely similar, differing only in the ordering of 2 lines or something like that
11:12:24
loke
beach: ah, you mean when you have (loop for x = (something y something) for y = (something x something) ...)?
12:25:14
stylewarning
phoe: show off your leet hacking skills with this code: http://codepad.org/1zalcTgI
13:29:59
beach
ebrasca: Take the documentation of the macro with-preserved-top-level-ness in this file: https://github.com/robert-strandh/SICL/blob/master/Code/Cleavir/CST-to-AST/variables.lisp
13:33:35
beach
ebrasca: It would be something that the user of the macro could read, and then he or she could use the macro without knowing how it is implemented. For example, in your case, it would document what variables the macro intentionally captures in the bodies that you pass it, and it would mention things like the fact that the code of the bodies is repeatedly invoked, how many times they are invoked, and how each invocation is different.
13:54:40
beach
ebrasca: For more documentation ideas, here is an example: http://metamodular.com/cluffer-documentation.pdf
13:57:28
attila_lendvai
did anyone see issues recently with cxml getting repeatedly reloaded by asdf?
14:00:49
Xach
I think there is a situation where multiple defsystems in a single .asd will cause unexpected reloads. Not just in cxml's complicated case.
14:02:19
Xach
https://github.com/mrossini-ethz/physical-quantities/blob/master/physical-quantities.asd triggers it, though
14:44:39
makomo
beach: since your documentation always looks solid, what's your opinion on literate programming?
14:51:54
pjb
makomo: just start your programs with #| and end them with |# Parenthesize the code parts with |# (code) #|
14:57:26
beach
makomo: I think the original idea is completely bogus. It was necessary because Pascal requires a very strict order between definitions and instructions, and that order is contrary to how Knuth wanted to present it to the human reader. The language we use does not have that restriction.
14:58:54
beach
makomo: So I guess my opinion about it will depend on how it is defined for a language such as Common Lisp.
14:59:57
dlowe
I kind of like the idea of an essay with code embedded in it that can be executed as a whole. But that's as a learning device, not as a programming practice.
15:00:02
makomo
beach: hmm. well if we put aside the fact that it was partly necessary because of Pascal's restrictions, what do you think about the general idea of literate programming: writing a book first and foremost and only then code
15:00:44
makomo
dlowe: yeah, i'm not sure how practical something like literate programming is when a program continues to evolve
15:01:30
makomo
for example, the Axiom CAS system uses literate programming (and it's written in Common Lisp + a language built on top of CL called SPAD)
15:01:33
beach
makomo: Well, I don't think there is a temporal order like that. But I do agree that the communication with the maintainer of the code is more important than communication with the compiler, if that is what you mean.
15:02:03
makomo
and there's also a book called "Understanding MP3" that uses literate programming with C to implement a full-blown mp3 parser and player
15:02:52
pjb
makomo: beach's right, see this article that passed on hackernews yesterday: http://lightsonsoftware.com/writing-code-that-reads-like-a-story/
15:02:54
beach
And, yes, I agree that the way literate programming is typically used, makes it totally impossible to have the code evolve.
15:03:18
pjb
beach: however, literate programming has the advantage that it stress on the human reader and documentation first.
15:03:35
asarch
beach, require('child_process').exec('ls', function(err, stdout, stderr) {if (err) {console.log("\n", stderr);} else {console.log(stdout);}}); in http://www.ecma-international.org/publications/standards/Ecma-262.htm
15:04:09
beach
pjb: So the challenge is to emphasize the communication with the person reading the code, while keeping the possibility of evolving the code.
15:10:29
Shinmera
makomo: Generally I think the documentation and the code should be separate. The code is an implementation detail, and requires a different level of description than documentation. Mixing the two together (as with literate programming) thus seems like a bad idea.
15:11:36
Xach
Who was it who, when paul graham said that arc code was its documentation, asked him if "inverts a matrix" was clearer than the code for inverting a matrix?
15:12:28
beach
Shinmera: Take a library for instance. The documentation for how client code should use it should be separate from the code.
15:13:11
beach
Shinmera: But the documentation explaining why the code is written in a particular way should definitely by next to the code, i.e. the maintainer documentation.
15:13:17
Shinmera
beach: When I say documentation I generally mean the user-facing one. Documentation about the internals would be comments.