libera/#commonlisp - IRC Chatlog
Search
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.
16:12:19
jcowan
A fair amount, but IL and CL developed independently for decades. Interoperation is good: CL sees IL functions and fexprs as CL functions and macros (although only some of them return an actual macro definition to CL:MACRO-FUNCTION.
16:13:55
Bike
i'm flipping through the manual now. seems to describe everything as a function... setq, for example
16:16:32
Bike
i was guessing that was what "nlambda" means, but selectq isn't labeled as one (while stuff like cond is)
16:17:12
Bike
"If LAMBDA-WORD is the symboL NLAMBDA, then the arguments to the function are not evaluated" i am a genius
16:17:53
beach
jcowan: And that still leaves duplication between the Common Lisp interpreter and the Common Lisp compiler.
16:18:22
jcowan
Such was the case in Maclisp as well. It was one of Scheme's contributions to CL that locals are lexical unless declared otherwise.
16:20:30
Bike
is interlisp an actual standardized language? i thought it was, but what i'm looking at is obviously an implementation manual
16:20:40
beach
I see. So the reason there is not as much duplication between the Common Lisp interpreter and the Common Lisp compiler is that the interpreter incorrectly uses dynamic binding for lexical variables?
16:24:14
Bike
yeah i can't tell if this thing is being weird about what is and isn't an nlambda. (rpl n form) "evaluates the expression form n times" but it's just listed as a function
16:30:28
beach
jcowan: What would be the special features of Medley that make it the preferred choice over a modern Common Lisp implementation?
16:31:16
beach
Interlisp obviously, but what makes Interlisp preferable to a modern Common Lisp implementation today? And why do you want Common Lisp as one of the languages in Medley?
16:33:34
jcowan
The work rquired to upgrade Medley CL to the ANS should be fairly small; the biggest part is figuriung out wht needs fixing.
16:34:22
jcowan
Admittedly, Medley doesn't look that much like a modern concensus IDE, but more so than Emacs.
16:35:00
Bike
the part of the manual about the environment is longer than the part about the language
16:38:37
jcowan
Maclisp effort wentt into building the language; IL effort into building the environment.
16:40:32
_death
jcowan: one question is how to conciliate a saved image and new changes in the medley repo
16:41:03
jcowan
I have also thought a little about what it would take to implement IL in CL, thus providing the Medley environment with the speed of a modern CL
16:46:17
jcowan
But beyond that you would, I hope, only need to implement the functions currently written in C.
17:40:56
lisp123
one of the ancestors of Common Lisp, there was a discussion earlier today on it. Apparently it had a very good development environment
17:46:48
cosimone
hello, is there some way, to your knowledge, to manipulate the internal representation of floating point numbers as something such as a bit vector?
17:54:28
Bike
there's also https://github.com/Shinmera/float-features which uses implementation specifics to get the actual bits, which is maybe what you want
17:58:58
yitzi
Bike: I saw in the ANSI spec that attempting to delete the cl or keyword package is unspecified behavior. Any idea why that would even be permitted? Some implementation prevent it and some actually let me do it.
17:59:35
Bike
when the standard says something like that i think it's more to let implementations be lazy by not putting in measures to prevent it, rather than because doing it is a good idea
18:00:28
yitzi
Amazing. CCL actually let me do it. SBCL gave me a pile of restarts and then let me do it and then promptly froze.
18:05:43
yitzi
Yeah, both tried to stop me with package locks. So far only ECL and CLASP said no outright. ABCL just did so without complaint.
19:08:38
recordgroovy
ABCL lets me define a condition inheriting stream-error, but doesn't let me apply stream-error-stream to it, hmm...
20:37:44
pjb
recordgroovy: this is indeed an error: (define-condition sec(stream-error) ()) (subtypep 'sec 'stream-error) --> T, T
20:38:26
recordgroovy
I've heard (but haven't experienced) that ABCL has a strange relationship with CL streams, as well