[HN Gopher] TimL: Clojure-like Lisp dialect that runs on and com...
___________________________________________________________________
TimL: Clojure-like Lisp dialect that runs on and compiles down to
Vimscript
Author : asimjalis
Score : 104 points
Date : 2023-05-26 07:21 UTC (1 days ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| ykonstant wrote:
| Is there anything like this on the works for Vimscript 9?
|
| Tangentially related: asking around in fora and in person, I was
| surprised to see that many plugin writers have had very good
| experience with the new Vimscript, and even prefer it to the more
| general purpose Lua (I was expecting the opposite). I myself have
| not used any Vimscript, but I am tempted to take a look at the
| new language.
| [deleted]
| ReleaseCandidat wrote:
| There are things I'll never understand. Why would anybody do
| this? Why Clojure and not Emacs Lisp?
| rollcat wrote:
| That would be awesome. Next step: run evil-mode on top of it.
|
| We've come full circle.
| roenxi wrote:
| Emacs lisp is a terrible lisp dialect. If it wasn't for Emacs'
| popularity it would have died decades ago. This is just one
| example in a _long_ line of examples where nobody willingly
| implements Emacs lisp. Even in Emacs there is pressure to move
| towards Common Lisp.
|
| Emacs lisp has, as far as I can tell, no advantages. It isn't
| especially good at text editing. It introduces differences from
| more popular lisp dialects. Anything it offers could be a
| library in some other lisp.
|
| Clojure on the other hand, has a couple of nice syntax
| innovations and smooth default data structures.
| jacknews wrote:
| "There are things I'll never understand."
|
| => true
| ReleaseCandidat wrote:
| Hmm, that's > "There are things I'll never
| understand." "There are things I'll never
| understand."
|
| for me. But > (cond ("There are things I'll
| never understand." 'true)) true
|
| works.
|
| Seriously I'm glad to not understand everything, that would
| be quite worrying and/or boring.
| tmtvl wrote:
| Some people like Clojure syntax rather than S-expressions.
| Personally I don't get it, having arbitrary lists that require
| square instead of round brackets, arbitrary lists where pairs
| which belong together aren't grouped, and arbitrary lists where
| commas are interpreted as optional whitespace gives me a
| headache; but to each his own.
| emmanueloga_ wrote:
| because the author wants it?
| capableweb wrote:
| Clojure is a language created and "controlled" by a single
| author (pretty unified overall) as a general purpose language,
| with implementations for multiple languages.
|
| Emacs Lisp (elisp) is a language specifically created as a
| scripting language for an editor, maintained by an
| organization, with one compiler (AFAIK) and 99% of usage is
| within Emacs.
|
| It's not hard to imagine people preferring Clojure before
| elisp, especially outside of Emacs.
| ReleaseCandidat wrote:
| To be honest, I would prefer Clojure to Elisp too.
|
| But to be frank, it's hard for me to imagine people
| preferring Vim over anything that isn't ed ;). Although, at
| least using ed you don't need to type the colons :)
| imran-iq wrote:
| This reminds me of a vim koan[0]:
|
| > Master Pope once dreamt he was an Emacs user. When he awoke, he
| exclaimed:
|
| > "I do not know if I am Tim Pope dreaming I am an Emacs user, or
| an Emacs user dreaming I am Tim Pope!"
|
| ---
|
| 0: https://blog.sanctum.geek.nz/vim-koans/
| twardowski wrote:
| [dead]
| capableweb wrote:
| Something similar: Fennel (https://fennel-lang.org/) is a lisp
| that compiles into Lua, which neovim can use as plugins, so you
| can write neovim plugins in a lisp. Aniseed
| (https://github.com/Olical/aniseed) makes this really easy.
|
| Aniseed is also used by Conjure (Interactive development
| environment for neovim, used for evaluating Fennel code inside of
| neovim), which is also made by the same author. Really great
| plugin for doing Clojure development with neovim.
| https://github.com/Olical/conjure
| nerdponx wrote:
| I use Aniseed, but it's worth noting that it's something like a
| "framework" on top of Fennel and Neovim. So I also want to
| shout out Hotpot, which is more of a simple plugin that allows
| you to put plain Fennel files in your runtime path, without any
| additional "framework" to learn.
|
| That said, I think the framework that Aniseed introduces is
| really nice, and I think would be useful for writing general
| purpose programs outside of Neovim.
| packetlost wrote:
| I'll second Conjure. I use it for (Gerbil) Scheme, and it makes
| it so much better. I really wish there was better support for
| non-Emacs editors in the Lisp ecosystem. Or really just a
| stronger Lisp ecosystem...
| giraffe_lady wrote:
| I've said this before but I think fennel is one of the most
| impressive languages around. Lua has a good reputation but I've
| used it professionally and find it one of the more practically
| painful languages to work in. Apparently fennel's author
| agrees, because fennel is laser-focused on correcting exactly
| its worst problems.
|
| AND/BUT one of fennel's impressive things is that it sticks
| rigidly to lua runtime semantics. Which I found a little
| repulsive at first but has huge benefits in its context. You
| can drop fennel into any version of lua on any runtime (bc they
| vary _a lot_ ) and it works the same. You can hook the single-
| file fnl compiler into lua's module loader and mix fennel files
| into an existing lua program, freely sharing functions and
| metatables both ways.
|
| Very flexible and powerful _because_ of that tradeoff. Anywhere
| I have to use lua now I am actually using fennel.
|
| The downside is this choice precludes it from having the
| clojure-like data structures and reference types. It _could_
| add a new standard library but doesn 't, limiting itself to a
| handful of special forms (notably pattern match thank god) that
| mix nicely with the existing lua primitives. It looks like TimL
| has gone the other way with that decision, which I also
| appreciate. Makes it maybe a less flexible general-purpose lua
| replacement/extension, but probably makes it more powerfully
| suited for the specific purpose it'll be used for.
| obiefernandez wrote:
| For maximum effect, read the following in Tim's distinctive
| voice:
|
| "Is this a joke?
|
| If you mean the 6,000 lines of working code, then no, I poured
| hundreds upon hundreds of very serious hours into that. But if
| you're referring to the fact it's woefully underdocumented, adds
| considerable overhead to an already slow host platform, and
| ultimately unlikely to gain any traction, then yeah, probably."
| twardowski wrote:
| [dead]
| EuAndreh wrote:
| Any sufficiently complicated Vim configuration contains an ad
| hoc, informally-specified, bug-ridden, slow implementation of
| half of Emacs.
| AlchemistCamp wrote:
| And its half doesn't include the repetitive stress injuries ;)
| avbanks wrote:
| A few years ago I would have hated you for this comment but
| after switching to Emacs, this comment is actually spot on.
| maleldil wrote:
| > slow
|
| There's quite a good chance that even the most complicated
| Neovim setup is faster than Emacs. Emacs lisp is notoriously
| slow, while Neovim uses LuaJIT, which is _very_ fast.
| bitwize wrote:
| Emacs Lisp had native-comp now.
| nequo wrote:
| How do Neovim and Emacs startup times compare when using
| Emacs 28's native compilation of elisp?
|
| Obviously hard to compare because they don't run the same
| packages but would still be interesting to see ballpark
| figures of setups with roughly equivalent functionality.
| edoloughlin wrote:
| Can anyone see how to start the repl?
| fatheart wrote:
| From the readme: Start a repl with :TLrepl. Tab
| complete is your friend. The first time may take several
| seconds (if your computer is a piece of shit), but compilation
| is cached, so subsequent invocations will be super quick, even
| if Vim is restarted.
| omoikane wrote:
| ELVM might be a related project, which takes C code and compiles
| to various languages, including VIM.
|
| https://github.com/shinh/elvm
| ducktective wrote:
| How difficult is it to write an "Emacs Lisp" interpreter in a
| foreign framwork like neovim? Wouldn't this basically convert any
| IDE into Emacs if the user wants it?
|
| I mean, I know elisp is not the most efficient of Lisp compilers
| but doing so for a new IDE opens the door for all available codes
| and plugins people have written for emacs throughout the years.
| hvis wrote:
| > Wouldn't this basically convert any IDE into Emacs if the
| user wants it?
|
| Emacs Lisp is only part of the equation. You need the all of
| the programmability that implements 90% of Emacs in Lisp (all
| of the standard library functions, the display engine, etc).
| zelphirkalt wrote:
| I think a huge compatibility layer would also needs to be part
| of that. Most IDEs probably use a completely different
| vocabulary and set of concepts than Emacs, starting with
| buffers and mode lines and minibuffers and modes.
___________________________________________________________________
(page generated 2023-05-27 23:01 UTC)