Post AdTR03lVjZLsJVJdh2 by robby@zoinks.one
(DIR) More posts by robby@zoinks.one
(DIR) Post #AdT9utbMOeSK7fWHrs by amoroso@fosstodon.org
2024-01-03T12:49:27Z
0 likes, 0 repeats
"Common Lisp is not a beautiful crystal of programming language design. It's a scruffy workshop with a big pegboard wall of tools, a thin layer of sawdust on the floor, a filing cabinet in the office with a couple of drawers that open perpendicular to the rest, [...]""This historical baggage is a price paid to ensure Common Lisp had a future."https://stevelosh.com/blog/2018/08/a-road-to-common-lisp/#CommonLisp #lisp
(DIR) Post #AdT9uuXUuUxb1yiiUC by galdor@emacs.ch
2024-01-03T12:52:26Z
0 likes, 0 repeats
@amoroso This why Common Lisp is still useful in 2023. Compare this to the neverending quest of Scheme for purity and where it led (hint: look at the R7RS shit show).
(DIR) Post #AdTAPB2u6UliudqHtQ by amoroso@fosstodon.org
2024-01-03T12:57:54Z
0 likes, 0 repeats
@galdor This is indeed what comes to mind when thinking about Lisp purity.
(DIR) Post #AdTCgEDZlMQna95n8a by zardoz03@mastodon.online
2024-01-03T13:23:24Z
0 likes, 0 repeats
@galdor @amoroso it also doesn't help there's like 4 or more interest groups for scheme beyond "i need a decently large amount of things to get things done quickly". the failure and controversies of the last 2 scheme standards is a case for BDFL-style direction like mr. hickey behind clojure
(DIR) Post #AdTR03lVjZLsJVJdh2 by robby@zoinks.one
2024-01-03T15:58:35.954274Z
1 likes, 0 repeats
@galdor @amoroso It is incredibly easy to be productive in writing useful Scheme (particularly R7RS actually, if you want to write portable code). The problem with Scheme is not a technical one; it is a cultural one. People usually use Scheme because they are more interested in language design than in writing software, and thus a smaller percentage of the already fairly small community of people who use Scheme are writing useful software in Scheme, than in other languages that have less academic cultures.
(DIR) Post #AdTdss428hePOqskUq by simon_brooke@mastodon.scot
2024-01-03T15:26:30Z
0 likes, 0 repeats
@amoroso It's the outcome of an essentially political, not technical, effort to prevent InterLisp becoming the #Lisp standard. Yes, I was there, a member of the BSI working group on Lisp. I didn't attend meetings of the American working group, but I did speak to people who did; and I've read what Guy Steele has written since.This is not to argue that InterLisp is a perfect Lisp, it isn't; but Common Lisp has features which were put there only to break compatibility.
(DIR) Post #AdTdssy2mSSCCZ5Tnc by amoroso@fosstodon.org
2024-01-03T15:42:14Z
0 likes, 0 repeats
@simon_brooke Thanks, that's what I suspected. The bottom line is it may not have made much difference to have more Interlisp features in Common Lisp.
(DIR) Post #AdTdsu1cqcufTxlr1M by lispm@moth.social
2024-01-03T17:49:18Z
0 likes, 0 repeats
@amoroso @simon_brooke I read Simon's unconvincing claims literally decades ago already. The reality was actually different: the people designing Common Lisp had different goals and compatibility with Interlisp and providing an Interlisp-like IDE was not one of their goals. And that was no secret. The purpose of the new language was listed here: https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node6.html#SECTION00510000000000000000
(DIR) Post #AdTdsv6yoCn2qrHe0O by lispm@moth.social
2024-01-03T17:56:31Z
0 likes, 1 repeats
@amoroso @simon_brooke Simon for example argued that, decisions like "comments were not preserved by the Lisp reader" and being a "Lisp-2" were made to introduce incompatibilities with Interlisp (see comp.lang.lisp Oct 1994 discussions with Simon).The reason to be a Lisp-2, was simply Maclisp compatibility. Scott Fahlman himself (we can still thank him that CMUCL and thus SBCL are public domain) answered him: https://groups.google.com/g/comp.lang.lisp/c/nNg90WTJuhk/m/sEIZkdh-0WsJ
(DIR) Post #AdUwMLHsYkIelVWLho by simon_brooke@mastodon.scot
2024-01-03T18:38:16Z
0 likes, 0 repeats
@lispm @amoroso Look, whether or not you like to develop software in a rich IDE is a matter of taste; but the Lisp1/Lisp2 issue is not. The arguments are set out perfectly clearly by Gabriel and Pitman in Technical Issues of Separation in Function Cells and Value Cells, and, as they say, "[a] major aspect of the Common Lisp movement was compromise along political lines." Cont'd...https://dreamsongs.com/Separation.html
(DIR) Post #AdUwMMEN3H5Vgut3sO by amoroso@fosstodon.org
2024-01-03T20:24:23Z
0 likes, 0 repeats
@simon_brooke Not sure I follow why Common Lisp going with Lisp-2 may have been a disadvantage for Interlisp: isn't Interlisp a Lisp-2 too?@lispm
(DIR) Post #AdUwMMzAFIWC22mQoS by simon_brooke@mastodon.scot
2024-01-03T21:05:33Z
0 likes, 0 repeats
@amoroso @lispm I think not, but I don't have an Interlisp machine available right now and it's two decades since I was familiar enough to say with certainty.In an Interlisp EXEC window, type the name of a function; if it returns a print representation of an executable object as the value, it's Lisp 1.
(DIR) Post #AdUwMNIf4o790Vu0Ce by simon_brooke@mastodon.scot
2024-01-03T18:40:49Z
0 likes, 0 repeats
@lispm @amoroso They go on to say, as the first line of their summary, "The bulk of arguments that focus on clean semantics and notational simplicity tend to favor uniting the function and value namespaces."Indeed. The committees stained and strained and gave birth to a camel, but the choice of a Bactrian rather than a Dromedary was a political one.
(DIR) Post #AdUwMNoZABdQbSpTvs by amoroso@fosstodon.org
2024-01-03T21:09:52Z
0 likes, 0 repeats
@simon_brooke Evaluating, say, CREATEW at an Interlisp Exec yelds:CREATEW is an unbound variableAccording to the Interlisp.org site:"Like Common Lisp but unlike Scheme, Interlisp is a LISP-2 language."https://interlisp.org/software/using-medley/cl-using/#lisp-2@lispm
(DIR) Post #AdUwMOXaSneCr5tR6e by simon_brooke@mastodon.scot
2024-01-03T21:47:35Z
0 likes, 0 repeats
@amoroso @lispm is that at an Interlisp executive or a Common Lisp executive?
(DIR) Post #AdUwMPFXpMoF3QSXce by amoroso@fosstodon.org
2024-01-03T21:58:33Z
0 likes, 0 repeats
@simon_brooke An Interlisp Exec.@lispm
(DIR) Post #AdUwMQ9CURKRq2UzNA by simon_brooke@mastodon.scot
2024-01-03T23:55:49Z
0 likes, 0 repeats
@amoroso @lispm right. In that case, I have been talking shit all this time, and must retire embarrassed!
(DIR) Post #AdUwMQl8DPfbjgFHUm by simon_brooke@mastodon.scot
2024-01-04T08:03:39Z
0 likes, 0 repeats
@amoroso @lispm h'mmm... Thinking about it overnight, it is clear I have been flat wrong on this for literally decades, conflating a number of separate issues. So to everyone I have argued with, my apologies.But a thread follows, rather awkwardly because in being wrong on this point, I've also been wrong on others.#1/n
(DIR) Post #AdUwMRbF5fM0LIctii by simon_brooke@mastodon.scot
2024-01-04T08:11:31Z
0 likes, 0 repeats
@amoroso @lispm In old #Lisp implementations which have both interpreters and compilers, it has (usually, certainly) been the case that there have been subtle semantic differences between the evaluation of interpreted and compiled versions of the same function, and this is really undesirable, leading to very hard-to-fix bugs.So the platonic ideal Lisp, sublimely ignoring exigencies of mundane efficiency, is probably interpreter-only.However ...#2/n
(DIR) Post #AdUwMSYRXYi1IuKAzo by simon_brooke@mastodon.scot
2024-01-04T08:18:27Z
0 likes, 0 repeats
@amoroso @lispm we live in the mundane world.But, when you print (or edit) the value of a function symbol, you always want the source form, and when you evaluate the function, you always want an efficient and semantically consistent form, which is to say, the compiled form. So now we immediately have two namespaces for function symbols, which are necessary for a good Lisp system which runs on real world hardware.#3/n
(DIR) Post #AdUwMTJEja8he2DXvs by hayley@social.applied-langua.ge
2024-01-04T09:29:55.148058Z
0 likes, 0 repeats
@simon_brooke @amoroso @lispm I'd also hope functions created from lambda forms run fast, so those functions need to have compiled code too. That suggests that the source form and machine code would be associated with a function object, regardless of symbols.
(DIR) Post #AdUwMUSUSf8TD1YRzk by simon_brooke@mastodon.scot
2024-01-04T08:25:42Z
0 likes, 0 repeats
@amoroso @lispm you also need some hidden under the table magic, because you need to be confident that what you evaluate is always a true representation of the code you see when you print.So either, when you bind a symbol to a lambda form, a side effect of that binding must be to cache an executable object compiled from that form in an under-the-table 'executable' namespace, or...#4/n
(DIR) Post #AdUwMWJhYJIGyLSSZc by simon_brooke@mastodon.scot
2024-01-04T08:30:30Z
0 likes, 0 repeats
@amoroso @lispm ...every time you evaluate a form whose car is a function symbol, you need to check whether the source binding of that symbol is newer than the executable binding, which means that every object header needs now to contain a timestamp in addition to all the type information and garbage collection flags and other assorted baggage it already contains.Remember when they said "a #Lisp programmer know the value of everything and the cost of nothing"?#5/n
(DIR) Post #AdUwMYPnkbMTTqKMMK by simon_brooke@mastodon.scot
2024-01-04T08:37:07Z
0 likes, 0 repeats
@amoroso @lispm I mean, it would be really nice if you could provide a second, timestamp, argument to 'print' which would print the binding which a symbol had at the specified time, and a similar additional argument to eval which would evaluate the expression with the bindings that were in place at the specified time, but the memory cost needed to provide that functionality would be... Large.#6/n
(DIR) Post #AdUwMaPsJIbngeNRke by simon_brooke@mastodon.scot
2024-01-04T08:43:27Z
0 likes, 0 repeats
@amoroso @lispm so while I continue to believe the ideal platonic #Lisp is a Lisp 1 with immutable data (but not immutable bindings, hush, don't point out the obvious inconsistency), all real world Lisps are necessarily compromises with the harsh realities of actual mundane hardware, and multiple bindings in multiple namespaces for the same name may be just one of those compromises.#7/n
(DIR) Post #AdUwMd8GDFIk6t9vDE by simon_brooke@mastodon.scot
2024-01-04T08:53:12Z
0 likes, 0 repeats
@amoroso @lispm so, in short, when you see me fulminating about the utter blasphemies that are SETF, RPLACA and RPLACD, or cursing the decisions in the design of Common #Lisp which see text in the file system, rather than expressions in core, as canonical, wave it away with "oh, that's Simon. He's quite mad, you know, poor soul."Which has the benefit of being true.#8/8
(DIR) Post #AdUxDOR9a0z7si9hI0 by amszmidt@mastodon.social
2024-01-04T08:23:57Z
0 likes, 0 repeats
@simon_brooke @amoroso @lispm Not so much "old" -- mostly just NCOMPLR based ones. The Lisp Machine compiler sorta fixed it and the issue of compiled/interpreted semantics was no more. Even in modern Lisp systems, you will have a compiler _and_ a interpreter since it is useful for various reasons.
(DIR) Post #AdUxDPBanM8ECjsmfo by simon_brooke@mastodon.scot
2024-01-04T09:30:14Z
0 likes, 0 repeats
@amszmidt @amoroso @lispm can you point me to a reference on this?
(DIR) Post #AdUxDQ4tTkMqyFkws4 by amszmidt@mastodon.social
2024-01-04T09:34:59Z
0 likes, 0 repeats
@simon_brooke @amoroso @lispm The Evolution of Lisp by Steele/Gabriel is probably the easiest place. I could dig through BUG-LISPM ...There are some Lisp systems that do away entirely with the notion of "interpretation" -- e.g., SBCL (EVAL calls COMPILE / FUNCALL). But they are generally in the minority .. even SBCL has a Lisp interpreter that you can use if you want too.
(DIR) Post #AdUxDQlmuGg97HpCjI by hayley@social.applied-langua.ge
2024-01-04T09:39:32.812903Z
0 likes, 0 repeats
@amszmidt @simon_brooke @amoroso @lispm EVAL calls COMPILE for lambda forms; it'll interpret so long as you don't use functions.(Which leads to some surprises - TIME expands to something like (CALL-WITH-TIMING (LAMBDA () ...)) and now you're compiling, even if the ... wouldn't hit the compiler before. Very bad if you have some macro which expands to thousands of LOC...somehow. Please don't do that.)