Module documentation for 0.2
A Haskell package for writing Emacs modules
Why would anyone want to write Emacs modules in Haskell?
Emacs Lisp is not a young language and can go quite a long way, but it has a couple of issues that are not going to be solved any time soon:
It’s dynamically typed which makes refactoring large extensions a pain
It’s intepreted and is quite slow. It might be argued that editors don’t need much computing power, but from time to time computation-intensive tasks do occur. For example, fuzzy matching provided by the cool flx.el package and used by great ivy.el package to quickly find things.
Somewhat related to the previous point, there’s virtually no support for parallelising computations. There’re adavances on adding threads to Emacs lisp, but this only provides concurrency, but no parallelism.
Haskell is well known for solving points 1 and 3 outlined above. For me it also solves point 2 by providing enough performance and adding parallelism on top of it.
If you think this might be a good idea and would like to see what this package can do for you, you can look at part of my emacs config that uses this package to implement things like
- Rewrite of
flx.elthat leverages parallelism
- Fast search across filesystem
- Concurrrent grep reimplementation (somewhat dubious since things like
- Rewrite of
How do I start writing my own extensions?
Some day there will be a proper tutorial for using this package. For the time being the best place to start is this package’s tests.
What about Windows?
It works, Cabal can build a dll for you.
How it’s related to haskell-emacs?
haskell-emacs aims to address the same problem - writing Emacs
extensions in Haskell, but uses different approach. It seems to use
some kind of marshalling scheme to make Emacs data available in
Haskell with a caveat that not all Emacs types can be converted (e.g.
buffers cannot be typically serialised). Presumably, an extension
built with this project will look like an executable that reads sexps
from stdin and produces output on stdout. Or, possibly, as a daemon
process that communicates with Emacs over network.
This project is a bit different. It wraps Emacs C API for writing new
extensions that can manipulate Emacs values directly, without
marhsalling. In this approach, an extension will look like a shared
library/dll that can be loaded by standard emacs with
Is there a tutorial?
Supported GHC versions
Tested with GHC
Major rework of the package’s core
Bump minimum required Emacs version to 28 due to exposing
process_inputfrom API. It allows to check whether user wants to abort and control should be returned back to Emacs ASAP
Bump minimum required
baseversion to 4.14 - minimum supported GHC is 8.10
Symbols can be either statically known or dynamically known. This is mostly an optimization that doesn’t affect symbol use but client code may require updating. Statically known symbol are just pointers to statically allocated (by GHC) bytes and the pointers are simply passed to Emacs to create symbols.
Some commonly used symbols are now cached on first use so they won’t be re-interned on subsequent uses. New symbols can be defined by users.
makeFunctionnow cleans up after itself and no longer has memory leak if called a lot of times (which shouldn’t have typically happened anyway but still nice to have just in case)
EmacsFunctionExtraare gone. They offered to pass extra pointer into subroutine exposed to Emacs but it was never needed since arbitrary closure can be exposed. Now extra pointer is used to clean up result of
extractUnboxedVectorWith- now regular
extractVectorproduces generic vectors
extractVectorWithand similar for other vector/array types are preferable since they’re guaranteed to not create intermediate vectors/arrays
Doctype for function documentation that can be constructed from unboxed string literals to just pass the pointer around
EmacsReturnare gone - vanilla
Symbol names got
IsStringinstance and can be defined as string constants
GlobalRefgot removed, instead
RawValueis indexed by whether it’s going to be GC’ed after returning control back to Emacs
funcallPrimitivenow accept any emacs value function rather than symbols only
extractTextis now part of
- Fix build with GHC 9.0+
- Switch license from BSD 3 to Apache 2.0
- Bump minimum required GHC to 8.10
- Bump minimum