drym-org / symex.el

An intuitive way to edit Lisp symbolic expressions ("symexes") structurally in Emacs
Other
271 stars 22 forks source link

add fennel support #134

Closed pbaille closed 2 months ago

pbaille commented 2 months ago

Summary of Changes

Trying to add interface for the fennel language.

Public Domain Dedication

(Why: The freely released, copyright-free work in this repository represents an investment in a better way of doing things called attribution-based economics. Attribution-based economics is based on the simple idea that we gain more by giving more, not by holding on to things that, truly, we could only create because we, in our turn, received from others. As it turns out, an economic system based on attribution -- where those who give more are more empowered -- is significantly more efficient than capitalism while also being stable and fair (unlike capitalism, on both counts), giving it transformative power to elevate the human condition and address the problems that face us today along with a host of others that have been intractable since the beginning. You can help make this a reality by releasing your work in the same way -- freely into the public domain in the simple hope of providing value. Learn more about attribution-based economics at drym.org, tell your friends, do your part.)

countvajhula commented 2 months ago

Hi! This is looking good. A couple of comments:

pbaille commented 2 months ago

Thank you for the quick review :) I tried to address your comments, tested locally and it seems to work ok.

I was also wondering if we could benefit from allowing the user to extend symex to a new flavor of lisp without having to touch symex code. Yesterday I tried this and it seems nice to me, what do you think ? (I am not very experienced with elisp but the idea is simple)

countvajhula commented 2 months ago

Re: the idea to allow addition of runtime support without modifying Symex, in most cases I'd hope that users would implement the support and contribute it to Symex so that others benefit (like you've done here!), but I can see how it could be useful as a fallback for fringe flavors of Lisp that may not be widely used, and it seems reasonable to support it. Do you think it would be worth it to reimplement the existing runtime modules (e.g. scheme, racket, etc.) using the same approach?

pbaille commented 2 months ago

Do you think it would be worth it to reimplement the existing runtime modules (e.g. scheme, racket, etc.) using the same approach?

By runtime modules, do you mean those symex-interface-*.el files ?

I think I could make sense to so if we go this way, but we will need an extra level of indirection. In the commit I linked previously, the implementations are indexed by major-mode, but looking at the symex-misc.el in some cases, several major modes map to the same implementation (using (member major-mode symex-*-modes) as condition).

So the state (that I called symex-interfaces in the commit) will have to take care of this. There is several ways to do this, I don't really know what would be the proper elisp way.

In the meantime I am wondering how much opacity that dynamism will bring and if it's worth it.

countvajhula commented 2 months ago

I'm not sure what the build failure on Emacs 26 is about but I've seen it in another package I've been working on recently, so I don't think it has anything to do with your changes.

This looks good, thank you for your contribution! I'll merge this and create a separate issue for the other discussion on interfaces.