Very nice article. I'll be interested to hear where you end up, with eglot or lsp-mode.

A quibble (based on my knowledge of Common Lisp, I'm not sure if it applies exactly the same way to Clojure):

"Language server has to do all of that statically, using their own parsers, tracking of variables, modules, and so on."

There's no reason an LSP server can't be run inside the Lisp image and integrate with its internal xref data. In fact, to do it any other way has serious problems due to Lisp's procedural macros making static analysis impossible.

Taking a quick look around, I see this is how the alive-lsp server works. You load it into your image and run (alive/server::start :port 8006)

It seems like this would address some of your complaints about the lack of fallback when looking for xrefs, because fallback wouldn't be necessary.

+1. Earlier than I thought. I had guessed 1989.

Gwydion Dylan has been out of the picture for years. Open Dylan is the only maintained implementation. Perhaps you went down a wrong path....

You can't bootstrap OpenDylan from source without a Dylan compiler. You can bootstrap Gwydion without one with substantial elbow work, which you can then pivot into bootstrapping OpenDylan.

I know what I was doing, and if you look elsewhere in the thread, I was right about what the GUIX maintainer wanted. Not to get egg on your face.

Yes. Making a macro for defining enums isn't that hard (there's one here: https://github.com/cgay/uncommon-dylan/blob/master/enum.dyla...).

I, for one, welcome my whitespace-surrounded operator overlords, but if you really don't want that you're welcome to use function-call syntax for them.

We also have Dylan. Just sayin'.

Opportunity lost or not, we're sticking with it, including preparing for a new release in the next few days (see our testing pre-release at https://github.com/dylan-lang/opendylan/releases/tag/v2020.1...).

That is interesting to know, I thought that after the LLVM integration it had stalled.

Looks like my tiny little website is being attacked. This will take some time to deal with. Sigh.

Are you sure you aren't just underestimating the traffic level HN can generate?

Possible! When I restart the server there are instantly hundreds of connections. If so many people are interested in Dylan, let's get some code contributions going, folks. :)

I think I've fixed (well, worked around) a bug that may have been part of the problem. It's working for me now.

Thanks for the interest, everyone. It never occurred to me this would end up on Hacker News.

Great, after a few previous attempts it finally worked for me on my first attempt after seeing this report.

Should be back up. I have a bug in the http server, which is also written in Dylan and hasn't been battle hardened, where it sometimes fails to close connections.

@cgay be great to see this integrated with the OpenDylan homepage (interactive examples) and a nice blog write up on how it works on the news/articles section. Very cool.

Thanks, that's the plan, although I hadn't thought about writing it up. :) It's pretty simple, really, but it has definitely highlighted the fact that there's a lot of work to do on the http server. I'm trying to decide whether to push forward with that or "just" provide Dylan integration with an existing web server framework, or maybe port Hunchentoot to Dylan with https://github.com/dylan-lang/lisp-to-dylan

< > is a naming convention for types (e.g., classes) only.

I know, but still makes the code ugly to my liking.

The Dylan language spec has amazingly few edge cases. It allows a continuum of dynamic -> static typing and a range of functional <-> OO. With the right set of libraries it could be great in the scripting space as Python, but is also designed for building large systems that run fast.