Add recipe for derl

[axelf4]

Brief summary of what the package does

The package provides two main features:

• A concurrency abstraction based on Erlang-like processes.

  Similarly to promises, processes allow writing asynchronous code in a natural way without nested callbacks, e.g.

  (derl-spawn
   (iter-make
    (! `(rex . ,node) `[,(derl-self) [call io format ("Hi!~n") user]])
    (message "Got back result: %S" (derl-receive (`[rex ,x] x)))))

  prints the string "Hi!" in the console of the node node, and logs the result when it arrives, without blocking in the interim.

  The embedding of processes is mostly faithful, but scheduling is not preemptive or in parallel due to being implemented in Emacs Lisp.

• Secondly, a means of communicating with running Erlang VMs from Emacs.

  The motivation is wanting to be able to implement something akin to lisp-interaction-mode for editing Erlang. For other languages, one way this has been achieved is by first uploading a TCP server on the VM (cf. nREPL or Nvim-R) that responds to editing commands. However, Erlang VMs, having first-class support for distributed applications, already expose an RPC server by default. One just has to communicate with the VM using the Erlang distribution protocol, which is what this package implements. (This necessitates having implemented processes.)

  As an example of how this is immediately useful: After doing M-x compile RET, executing

  (derl-do (derl-call (derl-rpc node 'c 'lm ())))

  would reload all modules that changed on the local node node.

See the package commentary for details.

This is reminiscent of the Distel Emacs package, which implements similar functionality and an "erlang-interaction-mode" on top. Derl is intended to fill the role of being "the core parts of Distel, had they been rewritten 20 years later." The derl README expands on the differences between the two libraries.

The name derl stands for Distributed Erlang. I am a bit torn on whether the name "earl" would be a better, more fun and unique, alternative.

Direct link to the package repository

https://github.com/axelf4/derl.el

Your association with the package

Author/maintainer

Relevant communications with the upstream package maintainer

None needed

Checklist

• The package is released under a GPL-Compatible Free Software License

• I've read CONTRIBUTING.org

• I've used the latest version of package-lint to check for packaging issues, and addressed its feedback

• My elisp byte-compiles cleanly

• I've used M-x checkdoc to check the package's documentation strings

  Yes, though there remains some warnings that I would prefer not to fix, in addition to false positives due to usage of cl-lib.

• I've built and installed the package using the instructions in CONTRIBUTING.org

[jcs090218]

I'm helping MELPA maintainers a little bit here.

• No byte-compile error 🎉

derl.el with checkdoc (0.6.2)

derl.el:36: There should be two spaces after a period
derl.el:39: There should be two spaces after a period
derl.el:40: There should be two spaces after a period
derl.el:64: There should be two spaces after a period
derl.el:67: There should be two spaces after a period
derl.el:33: There should be two spaces after a period
derl.el:102: There should be two spaces after a period
derl.el:352: All variables and subroutines might as well have a documentation string
derl.el:357: All variables and subroutines might as well have a documentation string
derl.el:391: Argument `fun' should appear (as FUN) in the doc string
derl.el:395: Argument `env' should appear (as ENV) in the doc string
derl.el:402: Argument `cell' should appear (as CELL) in the doc string
derl.el:484: All variables and subroutines might as well have a documentation string
derl.el:514: Argument `challenge' should appear (as CHALLENGE) in the doc string
derl.el:675: All variables and subroutines might as well have a documentation string
derl.el:703: Argument `gen' should appear (as GEN) in the doc string

derl.el with package-lint (20230905.629)

No issues found.

Package and license:

• GPLv3

[riscy]

Thanks @axelf4 - this is impressive. No blockers here.

[tarsius]

Since Distel already contains a library named derl, you should renamed your library. It is quite possible that someone would want to give your implementation a try, while still being able to use Distel, including their derl.

earl sounds fun to me.

[riscy]

Thank you @tarsius - I obviously missed this name conflict.

[tarsius]

earl sounds fun to me.

But there are people who are very much against fun names. So if you ever want to add this to Emacs, you should pick something more descriptive. Sadly. On second though, if you want to use a fun name, then by all means do.

[tarsius]

I obviously missed this name conflict.

Friendly ping!

[riscy]

I'm just taking another look at this now. So here is the library in question.

I hadn't heard of distel and I don't think it is indexed on any of the package managers (I checked ELPA, MELPA). But it also sounds like it's very popular and effective at what it does.

It has a few other files that reach outside of its namespace in its elisp dir. I'll add these to my exceptions list.

However, I feel like the best outcome here would be if @massemanet could tweak the distel namespacing so that everything sits under distel (or at least, for this case, rename his derl to distel-derl). If that's not workable for @massemanet, then it's probably a good idea for you to change your package name, @axelf4.

Apologies for this oversight - it's on me. :)