libera/#commonlisp - IRC Chatlog
Search
4:03:48
CptKirk
PAIP is much more profesionally written, though the density took me a while to get throught it
4:04:50
dualinverter[m]
I started with Land of Lisp because I had a copy of it lying around; it was a fun read until actual lisp learning started. After a couple of chapters, I found it disorienting.
4:52:23
dieggsy
is there some kind of compilation reader macro shorthand in the style of #+ for if a symbol is unbound
5:23:16
beach
I think what we need is a Common Lisp reference, probably in the form of a web site. I think this could be done by starting with the dpANS and adding more material.
5:28:05
beach
No, that's not good enough. It is a document primarily meant for creators of Common Lisp implementations.
5:29:06
beach
Yes, I saw that. We also have the fantastic work by scymtym to parse the dpANS into various formats.
5:29:22
moon-child
eh, I have no intention of creating a common lisp implementation, and I have always found it adequate. It could perhaps be made more approachable in some respects, but not majorly so
5:30:03
beach
moon-child: OK, example: Read the page on AREF and tell me what happens if you give it an object that is not an array.
5:31:50
specbot
The ``Arguments and Values'' Section of a Dictionary Entry: http://www.lispworks.com/reference/HyperSpec/Body/01_ddc.htm
5:32:27
beach
moon-child: Most newbies, and many experienced Common Lisp programmers don't know that. For example, jmercouris was convinced that an error would be signaled.
6:17:29
moon-child
as far as I know, there is no semantic difference between the way parameters are passed in elisp and cl. This snippet has the same behaviour in both, for instance https://0x0.st/-3ZM.txt
6:55:35
phantomics
Hey moon-child, I figured out what was wrong with {⍵{2÷⍨⍵+⍺÷⍵}⍣≡⍵}12345678 in April
6:56:42
phantomics
Because the 2 is handled as a rational number, the numerator and denominator get huge and the comparison tolerance doesn't work. A consequence of supporting ratios in April
6:58:50
pjb
emacs lisp passes parameters exactly like any other lisp, by value ! Always. CL passes parameters by value too.
6:58:53
moon-child
in raku, rational numbers will get automatically promoted to floats once the numerator/denominator exceed some threshold, unless you explicitly request otherwise. Such behaviour might be worth considering
7:00:20
moon-child
(perhaps the threshold might be when the denominator exceeds ÷⎕ct. That way rational comparisons can always be exact, with no semantic drawbacks)
7:01:32
moon-child
(rather than 'with no semantic drawbacks', I should say 'in a semantically consistent manner'. Except that that is not right...)
7:01:42
beach
moon-child: Also, the "Examples" section of many Common Lisp HyperSpec dictionary entries contains non-conforming code. For a creator of a Common Lisp implementation, it is known that these sections are not normative, but it is embarrassing that newbies are given such examples.
7:05:11
moon-child
beach: fair enough. What you point out about type mismatches I think is the sort of minor augmentation I mentioned would be helpful but not essential. In that it still describes correct usage of the function. But the non-conforming examples are more egregious (and identifying them is far harder to automate!)
7:07:07
beach
Sure, nothing is essential, but I think we can do much better than the Common Lisp HyperSpec in a reference document. For the AREF case, I could see the phrase "If an argument of a type other than an array is given, then the consequences are undefined" explicitly inserted.
7:07:31
beach
And when there is a phrase such as "an error should be signaled", at least making that phrase a link to the meaning of the phrase would be useful.
7:09:08
beach
lisp123: If you read the link you were give, you will see that Common Lisp, just like most modern languages (Haskell excluded) use call by value.
7:10:18
lisp123
beach: the tricky part is this "So, although values are copied before passed to the function, what is copied here is a reference."
7:11:23
beach
lisp123: Call by value just means that arguments are evaluated before a function is called. Nothing else. It says nothing about the nature of those arguments.
7:12:09
moon-child
wiki says 'if [a parameter] is used several times, it is re-evaluated each time it appears'
7:12:13
beach
I am sorry if the C++ people attempt to change established terminology, and I won't grant them that pleasure.
7:12:13
Nilby
The CL spec examples reinforce my belief in thinking for yourself and being skeptical of authority.
7:13:06
hayley
Well, given that evaluation of Haskell code is more or less deterministic, I think avoiding re-evaluation would be an optimization.
7:13:10
beach
lisp123: Again, "pass by value" = "call by value" means that they are evaluated before passed. Nothing else.
7:14:20
beach
lisp123: In all modern languages, when call-by-value is used, a copy of the value is passed, no matter the nature of that value. In certain languages, like C++ and Pascal, and Algol, you can change that by &name, var name, etc.
7:15:42
beach
lisp123: In early implementations of Fortran, this was not the case, so you could say f(1) and f could be defined with parameter x and then x = 2 in the body, and then subsequently, references to 1 would be 2.
7:17:06
lisp123
That link also is very helpful, with a bit more time I should be able to internalise the concepts
7:19:12
moon-child
hayley: no, because if you never evaluate an effectful form, the effect will not happen. For instance, this snippet prints nothing http://ix.io/3z7s
7:20:24
beach
hayley: Call by name, as I recall, is so weird that it was never implemented even in Algol.
7:20:44
hayley
Evaluating an effectful form in Haskell does not cause effects; the effect only occurs if it appears in the value bound to main in Haskell.
7:59:03
beach
I often want to say something like "there is no experiment the application programmer can conduct in order to determine whether some objects are not really references to memory, and are instead encoded in the pointer itself", but...
7:59:55
beach
Now that I think about it, an implementation can decide to "intern" certain numbers, and so the EQ experiment won't work.
8:01:40
beach
pjb: So we can be really nasty to people who try to exploit EQ-ness by having all integers and characters be real references, but we intern, say only odd numbers, and lower-case letters.
8:03:39
beach
OlCe: Indeed. But it is mostly the fact that, whenever I use the term "uniform reference semantics", some people like to point out that the implementation could be optimized in some ways, so that not all objects are references.
8:04:13
beach
Duuqnd: BOotstrap Common Lisp. A project to create a conforming Common Lisp implementation meant only for bootstrapping others.
8:04:35
beach
Duuqnd: It would be the only Common Lisp implementation optimized for maintainability rather than performance.
8:05:28
Duuqnd
I see. I've found two different repos, one is yours and the other is on gitlab. Which one are you referring to (I'd assume it's yours)?
8:05:47
beach
Duuqnd: To me, it is partly an argument against writing Common Lisp implementations in some language other than Common Lisp, for various reasons. Though I know perfectly well that jackdaniel prefer for ECL to be bootstrapped from C for other reasons.
8:06:28
beach
Duuqnd: It is complicated. I started mine, and then pjb started his own, and worked faster for some time, so I gave up. But then pjb got a full-time job...
8:07:51
beach
It is an amusing project to think about, in that it is really hard to avoid thinking in terms of performance.
8:10:34
Duuqnd
That's (a Lisp in C only) certainly useful to have. Is there a reason why ECL doesn't cut it (I'm not very familiar with ECL)?
8:11:16
beach
No, no reason. ECL is fine. But it is less maintainable than it could be, simply because performance is taken into account.
8:12:30
jackdaniel
ecl features two runtimes: one is inside a bytecode vm (and its a very trivial target without many optimizations) and one is compiled to C and then to native
8:13:26
jackdaniel
but then you defeat the purpose of having it as a bootstrapping tool - if you depend on ecl to bootstrap then you may stop at ecl right away
8:14:07
OlCe
jackdaniel: Not necessarily. You can compile an old version once and for all, and use that as bootstrap for newer versions, which are themselves bootstrap for whatever other compiler.
8:14:48
jackdaniel
the point is to have it bootstrappable from C, not from the previous version of the same implementation
8:14:56
beach
OlCe: The use case is what I said. Some Unix distributions want every program to be possible to build using only C.
8:15:48
Nilby
I could just slow down ECL for you? I think it's unlikely, given various examples from history, for a full CL in C to be practically any more maintainable than say ECL.
8:15:58
jackdaniel
my personal opinion is that the problem is already solved having both clisp and ecl, but the argument of better maintainability of bocl as the prime goal is a sound one regardless
8:16:26
OlCe
You are bootstrappable from C if starting with some fixed version (of say, BOCL) pre-compiled to C. You just distribute this C code as the first bootstrap.
8:16:34
jackdaniel
i.e ecl could be stripped from: networking, threading, native compiler, dlopen and various other extensions
8:18:02
jackdaniel
at the cost of performance, features and general usability. so that would be the primary difference between them: bocl would be only for boostrapping (because it would be rather useless in practice due to lack of common extensions); while ecl is meant to be used as the environment to write applications in
8:19:54
Nilby
beach: I think you write more maintaible code than most, but code has a way of developing it's own inertial momentum.
8:20:01
beach
Nilby: Imagine, for instance, every object being heap allocated, with a separate "header", so that CLASS-OF can be the same operation no matter what object type it is.
8:20:20
OlCe
Then, if you not only want a C bootstrap but also that such codeis easy to understand, pre-compiling to C might not be the best option.
8:21:02
beach
OlCe: Again, it also does not qualify as "source code" so can not be used in those Unix distributions.
8:21:59
jackdaniel
OlCe: it is a computer-generated code, so it is not the source, only an intermediate form
8:22:13
beach
No. "source code" is defined to be the "preferred version for modification by maintainers".
8:24:36
OlCe
Duuqnd: I think you could do that legally, but that's another problem (and discussion).
8:24:39
jackdaniel
Duuqnd: of course it could, but foss licenses does not imply such restriction (result of running the program is not the subject of its license)
8:25:15
OlCe
jackdaniel: Yes, this is what I had in mind. ECL runtime can be linked-in statically, but it can dynamically as well I think?
8:25:42
Duuqnd
I was under the impression that a compiler's author couldn't claim any copyright on the code the compiler generates
8:27:45
OlCe
beach: I'm very much interested in bootstrapping techniques, especially from C, but I'm not very sensitive to the "source code" argument.
8:28:32
jackdaniel
the point is that many people are sensitive to it. I believe that debian requires all software to be boostrappable from C (even indirectly, like C -> ECL -> SBCL)
8:29:24
jackdaniel
as of why C has such prominent position as "granted" - perhaps it had its merit 20y ago
8:29:27
OlCe
jackdaniel: But again, this is the case in all proposals above. What is not the case is bootstrap from true "source code", as mentioned by beach.
8:30:21
jackdaniel
I don't think that they would accept a C source code that is transpiled from something else (in a form that is not meant for maintanace)
8:31:24
jackdaniel
like the publisher would not accept a book translation being a result of putting the original in google translate
8:32:47
OlCe
jackdaniel: Especially since the C standard says "undefined behavior" in so many not-that-obvious cases, and most compilers viciously take advantage to optimize code away. And when you start doing nonsense, then it's best to optimize to the point where there is no more program at all.
8:32:50
jackdaniel
beach mentioned that there is a foss definition of the source code, so that would be the criteria for inclusion
8:33:29
OlCe
jackdaniel: I'm not in their heads, so I don't know for sure what they actually want behind this kind of restrictions, but
8:34:05
jackdaniel
as of undefined behavior there are various strategies to take advantage of it - and that depends on the compiler and on the platform
8:34:41
jackdaniel
i.e casting the function pointer to the data pointer makes perfect sense in a system where both are in the same address space, while it should result in an error otherwise
8:35:53
OlCe
jackdaniel: You don't have to update it to new versions of BOCL or others. You just bootstrap the new versions on top of it.
8:36:19
jackdaniel
well I can tell that your mind is set on certain ideas, so I'll leave the discussion at that
8:36:21
OlCe
jackdaniel: If it has flaws, you correct them by hand in C (if readable). In case of a big problem, you transpile again, but this should be fairly rare.
8:38:02
OlCe
jackdaniel: I'm exposing my assumptions and needs, in order to clarify where they differ from what you (and beach) are stating, nothing more. I'm not necessarily "set" as you say. And I perfectly understand and appreciate what you are saying. There is no contradiction.
8:38:44
jackdaniel
I'm not saying that you're not appreciating it. I'm saying that we've exchanged views and there is nothing to add ,)
8:41:14
jackdaniel
OlCe: I'd start here https://en.wikipedia.org/wiki/Source_code and check the [5] annotation regarding fsf definition
8:46:45
OlCe
jackdaniel: Entirely expectable from the FSF. This binds several distributions that absolutely want to abide by this definition and obtain or keep the FSF clearance. It's a problem I personally don't have.
8:48:47
OlCe
And this has not much to do with reproduceability, nor security (directly at least). It's a matter of ideology for those groups.
8:52:17
pjb
beach: it's even worse, since nothing says that implementation defined behavior cannot change over time.
8:53:32
hayley
I disagree that it is "a matter of ideology", given the damn point is to have usable source code.
8:55:23
hayley
Having a solid definition of useful source code is how we don't consider, say, all front-end code to be "free or open source software", or even anything distributed in machine code form only.
8:56:30
jackdaniel
if someone disagrees with the fsf point it is easy to look at it as ideology;; there is nothing wrong with that - opposite stance "I don't care" is also an ideology;; associating negative meaning with the word "ideology" is just a matter of sophistry
8:56:40
pjb
Duuqnd: writing C code is "painful" for anything. Only with time, C programmers become masochistic enough to bear it. Now when you're both a lisper and a C programmer, of course, you don't write the painful C code: you generated it with some lisp code! :-)
8:57:42
hayley
Perhaps I am still eating out of the trash can of ideology, by considering having access to useful source code to a good idea.
8:59:05
pjb
Let's say the difference between bocl and clisp, is that bocl aim to use standard C without using C implementation defined behavior or extensions, so that it can be compiled and run on all platform with a standard C compiler.
8:59:06
jackdaniel
OlCe: code may be readable, but it is also more verbose and harder to change by hand
8:59:07
hayley
OlCe: My non-normative opinion is that the C code produced is reasonable. But I would prefer to modify the Lisp code that it was generated from.
8:59:59
OlCe
hayley: But I'm very much separating the matter of modifying source code and the matter of bootstrapping.
9:00:03
hayley
I think my prior example of "all front-end code" is more illuminating though, particuarly with compressed JavaScript code.
9:00:22
jackdaniel
if it is the lisp code that you develop (say bocl) with, then this lisp code is the source code
9:00:28
hayley
While I get some source code, it is not useful for much one would want to use source code for.
9:02:28
hayley
OlCe: Okay then. But remember one approach for bootstrapping is to start with a pre-compiled Lisp image, and we have to determine why starting with C source code is better.
9:03:28
OlCe
hayley: Sure. I don't think bootstrapping with C is better in general. But in environments where only a C compiler is available, it's tremendously useful...
9:03:34
hayley
Oops, I said source code. "we have to determine why starting with mechanically generated C code is better."
9:06:16
hayley
Yes, I agree. So I guess the proposal for a bootstrapping Common Lisp is not too practical from this point of view. But it would be easier for the implementors to write the simplest code in C and then never touch it again.
9:07:03
OlCe
hayley: And for security matters, I prefer to be able to access as much source code as I want, a property I have with a C bootstrap (and open-source libc and compilers). I have absolutely no guarantee on this, nor practical and reliable means to verify it with a pre-compiled Lisp image.
9:13:25
beach
OlCe: I am personally not at all interested in bootstrapping Common Lisp from C. But BOCL to me is an argument against most "Debian" type arguments, since it would suffice for a pure Common Lisp implementation of Common Lisp (like SICL) to include BOCL in the distribution in order to qualify.
9:16:12
beach
And we had problems using SBCL for SICL bootstrapping in the past, because of decisions made in the name of SBCL performance. BOCL would not have any such restrictions due to performance compromises.
9:16:56
beach
We have not tried any other host Common Lisp implementation for bootstrapping SICL, but it would not surprise me the least if we ran into restrictions of this type in other Common Lisp implementations too.
9:18:56
OlCe
beach: Without taking too much of your time, out of curiosity, may I ask for types or examples of such restrictions? If you have pointers to web pages or papers instead, that's more than welcome as well.
9:20:12
beach
Well, first we created too many FUNCALLABLE-STANDARD-OBJECTs, because those used to all be allocated in something called "immobile space" (I think) and the size of that space was not increased by any arguments to the system.
9:21:03
beach
Then, we generated too big host functions, exposing some super-linear behavior of the SBCL compiler, so what now takes less than a minute used to take the better part of an hour.
9:30:38
OlCe
beach: The super-linear problem was an algorithmic mistake or oversight, or the consequence of a problem intrinsically hard to solve?
9:31:18
OlCe
beach: Because in the second case, you would have the same problem with BOCL compiling SICL. Anyway, now that you've fixed it in SICL, it doesn't matter much.
9:32:49
jackdaniel
same may go for other characteristics - the compiler may give up on analyzing too long function (because i.e compilation time grows exponentially with the function length)
9:36:41
beach
OlCe: It is not uncommon for optimizing compilers to have some quadratic algorithms, by necessity.
9:37:11
beach
And I can very well imagine the maintainers of some Common Lisp implementation being unwilling to fix such issues, citing the unusual use case.
9:39:05
beach
So I fear a situation where one day I add some feature to SICL, start the bootstrapping procedure, and I will run into some arbitrary restriction that can't easily be fixed.
9:40:08
beach
So, yes, I think those are restrictions that were introduced for reasons of performance. Which won't be a problem with BOCL.
9:41:57
OlCe
Mmm, yes. But some are more or less unavoidable. Plus, I assume you also expect SICL to compile SICL (same or other version), which may trigger quadratic (or worse) behavior as well, don't you? The host functions' size seems to be a problem that had to be fixed in SICL anyway.
9:43:49
jackdaniel
some compiler optimizations may be necessary to make a certain code compilable - i.e for deeply recursive functions a tail recursion may be necessary
9:44:17
jackdaniel
so either bocl will need to have certain optimizations or you may need to avoid certain constructs in the compiled code
9:45:24
OlCe
Most of the time, I consider deep recursion to be a bad idea, and I make the effort to rewrite the code into non-recursive form.
9:46:52
beach
Also, I think BOCL would be an amusing community project. Most people here seem to know some C.
9:47:11
jackdaniel
well, this is just one example; another would be a function length - I remember we've hit a certain issue with C compilers when using ECL to compile magicl
9:48:09
OlCe
jackdaniel: In practice, don't all reasonably alive CL implementations implement tail-recursion?
9:48:10
jackdaniel
the answer was to split the function into number of smaller functions spread in files
9:48:40
jackdaniel
OlCe: tail recursion is not always desired - i.e it makes debugging harder; so that would depend on the optimization settings
9:49:03
Nilby
The old lispers didn't have this problem. They had already first written a slow lisp, in a crap language.
9:49:13
jackdaniel
ecl native code depends on the underlying c compiler (but it makes a certain effort to make the tail recursion possible for the c compiler)
9:49:59
beach
OlCe: Maybe not. If you have a Common Lisp implementation that is compatible with the C calling convention, tail-call optimization is very hard.
9:52:26
jackdaniel
there is a certain trick called cheney on the mta: https://plover.com/~mjd/misc/hbaker-archive/CheneyMTA.html it utilises a certain trick to make it work (but it requires certain decisions to be incorporated in the implementation)
9:52:42
hayley
Nilby: Then they have the problem of having only a slow Lisp, and recovering from headaches induced by writing in crap languages.
9:55:42
Nilby
The evolution of Dylan is also intersting. The people a with lot of resources wrote the proprietary Dylan in CL. Then the free community wrote a slow one first in C, than transpiling to C.
9:57:09
jackdaniel
hm, since the program they wrote in cl was way too slow I guess that switching the language was the right choice
9:57:29
jackdaniel
it might be because they had no good implementation at hand or hardware was too slow or that they were poor cl programmers
9:59:06
jackdaniel
beach: first hand testimony: https://docs.gimp.org/2.10/en/gimp-introduction-history.html
10:00:32
hayley
"Something that did not rely on nested lists to represent a bitmap." Excuse me what the fuck
10:01:29
jackdaniel
mind that they were students on whom lisp was forced on :) still core dump at 17mb in cl is a bad taste, a sensible restart sounds better ,)
10:01:44
jackdaniel
also that might be an exaggeration after being frustrated with cl, they could actually have used arrays
10:03:45
OlCe
jackdaniel: Yes, but you would have the same problem in C, which could as well be solved in CL.
10:04:31
jackdaniel
I'm not going to take a bait and discuss whether C or CL was more practical on machines with 32MB ram ;) I'll be back later
10:06:55
Nilby
I can say from experience a Lisp GUI running on 32MB on CMU lisp was so slow it could barely trace my mouse.
10:08:41
beach
jackdaniel: I see. Though "Common Lisp" does not dump core. Some implementations might, of course.
10:11:15
jackdaniel
beach: sure; but it is very likely that what they had was an ancient hardware (compared to today) and imlementation that was inferior if you compare results of writing the same program in C and CL (performance-wise) on said hardware
10:11:33
Nilby
Sadly, I can still get any lisp on unix to dump core. Recently I made sbcl wedge the kernel.
10:11:59
lisp123
Why do people choose to use scheme as their scripting language for their applications? Is it because it is "smaller" than CL? Is it worth having a subset of "CL" for quick use
10:12:42
jackdaniel
lisp123: people with the same idea as yours standardized the programming language interlisp
10:13:28
jackdaniel
notably the interlisp project (supposedly) drained the project eulisp from competent developers (and eulisp was more interesting than internlisp)
10:13:36
hayley
lisp123: Well, there was a Usenet thread called "Ousterhout loses the plot" or something, where it is more or less argued that CL was deemed doubleplusungood due to 1. having long names and 2. having implementation authors who thought they could write fast implementations.
10:16:03
hayley
lisp123: This one: https://groups.google.com/g/comp.lang.functional/c/xLNt2BU34SA/m/IiAMlVFT22gJ
10:17:24
beach
lisp123: What is interesting, though, is that they choose a static language for the core application, citing performance. Then they include a scripting language in the form of an interpreter. Then people start writing code using the scripting language, because they can't do it in the static language. Then the combination is much slower than if they had chosen a dynamic language for both.
10:17:26
lisp123
I might sound out of line, but that John Ousterhout fellow doesn't sound too smart..
10:18:07
beach
Oh, I think he is smart. But he wasn't very knowledgeable in the past, like when he wrote TCL.
10:18:27
lisp123
beach: lol - based on how they wrote the starting notes to the GIMP history, it seems logical they went down that route
10:19:00
hayley
There is a smattering of familiar names in that thread, oddly enough, including Robert Virding, Rainer Joswig, Henry Baker, Doug Lea...
10:19:00
beach
lisp123: In addition, this combination of a static and a dynamic language easily turns into a debugging nightmare.
10:27:41
lisp123
It would be cool to have a mini CL, basically the basics of lisp but with CL's rules in mind
10:33:36
lisp123
I read the wiki page for interlisp, it mentioned that as an open source project, so probably it
10:43:01
hayley
"There are far more ugly programs than ugly languages. Using a 'good' language does not guarantee pretty programs. In fact, since a 'good' language has immense power, it is possible to write uglier programs in a 'good' language, than it is to write ugly programs in a 'bad' language. This, of course, is one of the justifications I've seen for forcing people to write in 'bad' languages !!" -- Henry Baker
11:02:56
Nilby
I should remember to cite Henry when I use the overwhelming power to write egregiously ugly code.
13:20:58
hayley
I'm settling a little discussion about persistent data structures now: when was the last time you (the reader) destructively modified a list?
13:22:04
Bike
i don't remember the exact context, but it was along the lines of (loop ... nconc (loop ... collect ...))
13:23:28
hayley
(I guess bonus points if your list would have been allocated in a previous GC cycle, but that is not something people pay attention to.)
13:25:44
Bike
mm, for modifying something more persistently, i don't recall... maybe altering an alist
13:27:52
beach
I think I do it every day. Cleavir instructions have a list for inputs, for outputs, and for successors. I think we sometimes destructively modify those.
13:32:28
hayley
(SETF NTH-SUCCESSOR) and INSERT-INSTRUCTION-BETWEEN do indeed destructively modify lists, yes.
13:36:08
mfiano
Come to think of it, I rely on my implementation performing a lot of (potentionally) destructive list operations.
13:37:50
hayley
Seems I am doing something unusual, as I rarely write code which mutates lists...ever, I think.
13:39:11
hayley
Very funny, a NBHM is just a vector with some glitter glued onto it. And when I mutate sequences, I usually reach for a vector.
13:43:55
mfiano
I usually reach for the sequence that makes sense. Norvig-style queues and fixed array queues are both useful in different situations for example.
13:44:57
hayley
Usually I just use safe-queue (as most of the time I use queues in a concurrent program too). But then the queue in sb-concurrency uses a list internally.
13:50:53
Nilby
I know it's shameful, but a quick count of some potentially list mutative keywords in my current codebase: nconc 66 rplaca 10 rplacd 26 "\\(setf \\(car" 13 "\\(setf \\(cdr" 15 "nreverse" 209
13:53:24
mfiano
RPLACA/RPLACD annoy me as names, where the convention is to descriptively name your operators, so I barely ever use them. Reminds me of writing an assembler :/
13:58:36
mfiano
_death: Did you like the Paepcke book? Just received my copy, and will probably start reading it later today.
14:01:26
_death
mfiano: it's a collection of papers.. many were very interesting.. there were a few that I didn't care for
14:07:40
mfiano
_death: Ok. By the way, feel free to recommend any other Lisp books you liked. You have recommended 2 I have never heard of so far (the previous being Building Problem Solvers)
14:08:50
Nilby
mfiano: I agree. I wish I could convice my fingers not to type junk like (rplacd (nthcdr ... since it reads like nonsense.
14:09:46
_death
well my favorite programming book, which is also a Lisp book, is PAIP.. which you probably already read
14:15:29
_death
some books I would not call "Lisp books" but do use a kind of Lisp in a low-key way.. for example Hoare's Communicating Sequential Processes book
14:23:28
_death
one way to make a book into a Lisp book is to implement everything it talks about in Lisp as you read it ;)
14:25:59
_death
some books are easier to implement (e.g., they have pseudocode).. others require you to read part of their bibliography & other resources found on the web
14:27:07
_death
then after you read the papers and implement them, you understand where the author put more effort, and where he skimped ;)
14:29:50
_death
some papers are quite cryptic.. others build on other papers.. so you can spend a month implementing ideas from a paper and its related papers, even if the paper was a few pages
14:31:20
_death
sometimes there is not enough information to make it easy to test your implementation..
14:31:33
lukego
I had forgotten about the Lisp in CSP. I love that book, even based on its non-Lisp content :).
14:31:43
mfiano
I have given myself more freedom from gamedev this year to explore other programming interests, and that is exactly something i wanted to do
15:58:38
jcowan
Medley is a programming environment that provides two languages: Interlisp and Common Lisp. Unfortunately, the CL stands somewhere between CLtL1 and CLtL2. This needs fixing.
15:59:21
jcowan
It would pretty much be a Common Lisp project to do so, and I would expect that the CL test suite could drive it.
16:02:24
jcowan
There is an IL interpreter, a CL interpreter, an IL compiler to bytecode, and a CL/IL compiler to bytecode. There is no native code compiler.