_19qg

> However, the point of all this discussion is that Lisp doesn't provide good enough language servers for modern editors,

They use the "language server" model since a long time, before Microsoft's LSP existed. Thus the need isn't really there, unless one wants to develop with Microsoft products (or similar) and get the needed extensions for Lisp into those Microsoft driven standards. If there were a real need and a real benefit, there would be some better adoption on the Lisp side.

> That's exactly what I get out of the IDEs I've used for decades. This whole argument is so weird, disingenuous, and full of vague strawmen. Just because I don't see the value in investing the time that you have doesn't mean that I'm for giving up control or whatever you were trying frame me as.

I used IDEs also all the time. Makes sense to me.

> Anyway, I'm done here. This site is full of toxic people who are offended that someone doesn't choose the same editor and habits that they do, and any dissent is to be punished.

Yeah, that's weird. You can use all kinds of editors you like. In the case of Lisp, there are arguments that good support for editing Lisp and for interaction with a Lisp runtime is useful (since Lisp is often used interactively). But several IDEs and editors can do that.

Just wanted to give you the impression that are others, who like IDEs and similar tools. ;-)

Can't say what and Interlisp did, but the MIT Lisp Machine and here the commercial variant Genera.

Files are versioned. The Lisp machine file system has versions (same for DEC VMS and a few other file systems). Nowadays the file version is attached to the name&type. Thus editing a file and saving it creates a new file with the same name&type and an updated version number. I can edit/load/compile/open/... files by specifying its version number. If there is no version number specified, the newest file version is used.

A site shared a namespace server with system registry and several file servers.

Code, documentation, etc. is defined as a system, similar to what ASDF does. A system has major and minor version numbers and other attributes (like being experimental or being released). Each time one does a full compile on a system, its major version gets updated and it tracks which file versions it used for that compilation. Whenever one creates a patch (a change of the sources) to a system, the minor version gets updated. After 12 full compiles and 30 patches to the latest version we have system FOOBAR 12.30. This data is recorded in the system directory, thus outside of an image (called a World in Genera) in the file system.

Now I can use that system FOOBAR in another Lisp and "Load System FOOBAR :version Newest" -> This will load system FOOBAR 12.30 into its runtime. Then new patches may appear in the system. I can then in a Lisp say "Load Patches FOOBAR" and it will look into the system directory for new patches to the current loaded major version and load those patches one by one. This changes the running Lisp. It then knows that it has loaded, say, FOOBAR 12.45, what files it has loaded and in which files the respective code (functions, ...) are located.

If I want to ship a system to the customer or someone else, I might tag it as released and create a distribution (with sources, documentation or not). The distribution is a file (also possibly a tape, a bunch of floppy disks, a CDROM, or similar). A distribution can contain one or more systems and its files (in several versions). On another Lisp I can later restore the distribution or parts of it. The restored systems then can be loaded for a specific version. For example I can load a released system version and then load patches for it.

A saved image knows which versions of what systems it includes. It also knows which functions sources are where. It may also have corresponding documentation versions loaded.

Later a source versioning system (called VC) was added, but I haven't used that.

That has been done in the past and was never widely supported. But the landscape is now slightly different. One approach might be to use ASDF (the most popular systems management tool), which then would need to be upgraded to use versions (and ideally have it integrated into a repository mechanism -> Git or similar... Also what are versions in a decentralized world?). ASDF operations then would need to be able deal with version numbers.

A Lisp image would then know/track which versions of what code it has loaded/compiled/... Version information would be stored with the other source files.

There is already confusion. Things are different and the same words (executable, native, image, ...) mean slightly different things.

In the CL world it is usually relatively easy to create an executable. For example in SBCL I would just run SBCL and then save an image and say that it should be an executable. That's basically it. The resulting executable

* is already native compiled, since SBCL always compiles native -> all code is AOT compiled to machine code

* includes all code and data, thus there is nothing special to do, to change code for it -> the code runs without changes

* includes all the SBCL tools (compiler, repl, disassembler, code loader, ...) thus it can be used to develop with it -> the code can be still "dynamic" for further changes

* it starts fast

Thus I don't need a special VM or special tool to create an executable and/or AOT compiled code. It's built-in in SBCL.

The first drawback: the resulting executable is as large as the original SBCL was plus any additional code.

But for many use cases that's what we want: a fast starting Lisp, which includes everything precompiled.

Now it gets messy:

In the real world (TM) things might be more complicated:

* we want the executable to be smaller

* we want to get rid of debug information

* we need to include libraries written in other languages

* we want faster / more efficient execution at runtime

* we need to deliver the Lisp code&data as a shared library

* we need an executable with tuned garbage collector or without GC

* the delivery structure can be more complex (-> macOS application bundles for multiple architectures)

* we want to deliver for platforms which provide restrictions (-> iOS/Apple for example doesn't let us include a native code compiler in the executable, if we want to ship it via the Appstore)

* we want the code&data be delivered for an embedded application

That's in the CL world usually called delivery -> creating an delivered application that can be shipped to the customer (whoever that is).

This was (and is) typically where commercial CL implementations (nowadays Allegro CL and LispWorks) have extensive tooling for. A delivered LispWorks application may start at around 7MB size, depending on the platform. But there are also special capabilities of ECL (Embeddable Common Lisp). Additionally there were (and still are) specialized CL implementations, embedded in applications or which are used as a special purpose compiler. For example some of the PTC Creo CAD systems use their own CL implementation (based on a ancestor implementation of ECL), run several million lines of Lisp code and expose it to the user as an extension language.

> I didn't say "type declarations can lead to a messy middle ground in Common Lisp" - obviously they exist there for a reason, but, maybe they DON'T exist in Clojure, also for good reasons, no?

What were those reasons?

> ABCL does exist, sure,

Would that count as a hosted implementation?

> And yet UCSD Pascal was using a P-machine. So, the problem was the implementation and not the concept. Which was exactly my point.

My point is that implementations don't come from nothing. You can't just demand them to be there. They have to be invented/implemented/improved/... Companies at that time did not invest any money in micro implementations of Lisp. I also believe that there was a reason for that: it would have been mostly useless.

> Temporarily. But then it died when the big money went away and left Lisp all but dead. All the while all the people using languages on those "toys" kept right on going.

Lot's of toys and languages for them died.

> Lisp would have been really good relative to BASIC interpreters at the time

I see no evidence for that. Lisp was a pain on tiny machines with bad user interface.

> 64K is solid for a Lisp if you own the whole machine.

I had a Lisp on an Apple II. It was a useless toy. I was using UCSD Pascal and Modula 2 on it. Much better.

I had Cambridge Lisp on an Atari with 68k CPU. It was next to unusable due to frequent crashes on calling FFI functions.

The first good Lisp implementation I got was MacScheme on the Mac and then the breakthrough was Macintosh Common Lisp from Coral Software.

> Had one of the Lisperati evangelized Lisp on micros

There were articles for example in the Byte magazine. Lisp simply was a bad fit to tiny machines. Lisp wasn't very efficient for small memory. Maybe with lots of work implementing a tiny Lisp in assembler. But who would have paid for it? People need to eat. The tiny Lisp for the Apple II was not usable, due to the lack of useful programming environment.

> Alas, they were off charging a gazillion bucks to government contracts.

At least there were people willing to pay for it.

> Lots of us hated doing assembly language programming but had no real alternative.

I kind of fail to see Lisp as an alternative to assembler on mid 80s micros.

Though, there were several cheap Lisps for PCs...

> The OP has a good criticism of why this is a bad idea. It's an old idea, mostly from LISP land, where early systems saved the whole LISP environment state. Source control? What's that?

Symbolics Genera can save (incremental and complete) images (-> "Worlds"). The image tracks all the sources loaded into it. The sources/files/docs/... of the software is stored on a central (or local) file server.

I can for example start an initial world and load it with all the wanted software in the various versions I want. Maybe I save a new world from that.

I can also start an pre-loaded world and incrementally update the software: write patches, create new minor/major versions, load patches and updates from the central server, install updates from distributions, ... Maybe save new worlds.

The "System Construction Tool" tracks what code is loaded in what version from where.

A bunch of things work in implementations, while but are not standard conforming.

actually, according to the LOOP syntax, the REPEAT clause has to follow the FOR clause...

> So I can replace my #3 above to wrap something with quotes instead of parentheses.

That's M-" .