Emacs Lisp as a Racket Language?

[Greg Davidson]

Is there interest in creating a Gnu Emacs Lisp Racket Language, along with the underlying APIs (perhaps tied to DrRacket) sufficient to compile and run Gnu Emacs Lisp extension packages? Is there prior or ongoing work for such a project?

For some years there has been an attempt to port Gnu Emacs to run under Guile Scheme. A big stumbling block is the vast amount of extensions written in Emacs Lisp and continuing development thereof. Racket seems to be a *much* better platform for such a project than Guile, don't you think?

_Greg (a long-time ambivalent Emacs user tired of Emacs Lisp)

[Joel McCracken]

This is an excellent idea. I have no idea if this is being worked on,
but I would love to help such an effort.

> --
> You received this message because you are subscribed to the Google Groups "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to racket-users...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Matthias Felleisen]

Guile has adopted a lot of Racket ideas. So they are building the platform to which to port Emacs.

Consider building Emacs in Racket and then building a sane API. This project probably requires an even longer time horizon. Tony Garnock-Jones of Marketplace and Minimart (see (fourth RacketCon)) fame has started the project. I am sure he's willing to take contributions.

-- Matthias

[Neil Van Dyke]

Reimplementing GNU Emacs, with backward compatibility, was one of the
original intents of Guile, but that never happened. (I won't get into
the reasons I know of, but a big indirect one was not due to any fault
of Guile or its people, IMHO, nor were they likely even aware of it.)

Implementing Emacs Lisp as a transformation to `racket/base` (as opposed
to a bytecode interpreter) seems doable, but nontrivial. You have to
handle dynamically-scoped variables, you have to implement the buffer
primitives efficiently, and (ideally) you need to permit the same
debugging interface (the Emacs stepper was way ahead of Racket, but
relies on a simple interpretation model). Emacs is built upon a core of
"primitives", some of them impressive, some kludgey, and then tons of
often-kludgey Emacs Lisp atop the primitives.

An alternative is to forget about Emacs Lisp backward-compatibility, and
just reimplement an Emacs-like editor/framework in Racket. DrRacket has
a little bit of Emacs nature, but that was not the goal of DrRacket (nee
DrScheme); if you implemented a Racket Emacs-like editor/framework from
scratch, I think it would end up very different than DrRacket, and more
nimble. The result of a non-backwards-compatible implemented in Racket
could also be less-kludgey. You might also think of it not as an
editor, but as an alternative GUI framework (and build in an HTML5
option from the start, while you're thinking at that level).

Neil V.

[Ed Maphis]

Or try porting MIT/Scheme's Edwin editor to Racket.

[Greg Davidson]

Thanks Matthias ... there's nothing on Tony's projects pages so I've sent him a message. _Greg

[Jens Axel Søgaard]

https://github.com/tonyg/rmacs

Also: Read this free book:   

    http://www.finseth.com/craft/

2015-07-02 23:00 GMT+02:00 Greg Davidson <greg.d...@gmail.com>:

Thanks Matthias ... there's nothing on Tony's projects pages so I've sent him a message.  _Greg

--
You received this message because you are subscribed to the Google Groups "Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to racket-users...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

--
Jens Axel Søgaard

[Greg Davidson]

I've implemented three programmers' text editors in days gone by, two of which were inspired by Emacs. It's easy to improve on Emacs' architecture and implementation but that just guarantees that the new improved editor will languish in obscurity since it doesn't have the momentum of the official Emacs. An editor would have to be truly extraordinary (including it's collection of extensions) in order to win power users away from Gnu Emacs. Like many long-term Emacs users, I'm unwilling to give up its power and convenience despite having to hold my nose a lot!

If a Free Software reimplementation was fully compatible with Gnu Emacs at the Emacs Lisp level, it could also provide a superior architecture underneath for new code written nicer Racket languages. Unless and until the new editor wins over most of the users of the existing Gnu Emacs, it is critical to maintain backwards compatibility for traditional Emacs Lisp and the traditional API.

Implementing Emacs Lisp presents a possibly interesting challenge to Racket's language framework. It may help that Emacs Lisp now supports lexical binding clearly signalled on a per-module basis.

_Greg

[Greg Davidson]

Thanks Jens! _Greg

[Michael Titke]

I don't think elisp makes much sense out of Emacs. There is nothing
special about it as a programming language: it's Lisp (and not Scheme)
and depends on "primitives" of a text editor "frame work" from the 80s.
Porting individual modes or features to Dr Racket (or even Viper/VSI)
might give better results then reimplementing the intrinsics of the
overall Emacs package. But that depends on the expectations and
intentions of the programming users.

[Rickard Andersson]

I think if there is a direction to go in, it's to make a SSH-friendly and
truly extensible text version of DrRacket. I would use this all day; I
only really use vim because it's terminal friendly and the editing is
great.

DrRacket offers a lot in terms of integration with Racket facilities and I
would rather have a text version of that than more Emacs/vim.

[Alexander McLin]

No question, this would be a challenging project.

Do a clean room fresh implementation or provide full Emacs Lisp compatibility? Would it make sense to consider doing a strict subset of Emacs Lisp, with sufficiently flexibility to allow popular extensions run while leaving others behind?

Common Lisp tried a clean room approach a long time but unfortunately it ended up languishing. They had some very interesting ideas based on an interface framework that I understand were heavily inspired by Geneva Symbolics Dynamic Windows.

Their attempt, Climacs https://common-lisp.net/project/climacs/ which was based on https://en.wikipedia.org/wiki/Common_Lisp_Interface_Manager

From what I've seen so far, it appears they generalized the buffer idea to handle arbitrary data, both text and graphics in a more systematic way. They had an example of browsing a file system with all the file icons and clickable expandable nodes right within the buffers.

Worth it checking to see if their ideas can be reused.

[Greg Hendershott]

So I've spent a lot of time using both Racket and Elisp over the past
couple years. My feeling:

- Racket is much nicer.
- Elisp is not nearly as bad as I first thought.


Some other baseless opinions:

1. An "opposite" approach would be to put a more Rackety face on
Elisp. But. I feel it's probably helpful (and interesting) to know the
real deal.

I was excited to discover the dash.el package, which puts a
Clojure-ish face on some things. Having said that, I'm now using it
less.

For example, I love using Racket match to do combined conditional and
binding. I started using if-let from dash to do the equivalent in
Elisp. Then I realized Emacs already provides pcase; so I'm simply
using that these days. (Although not as comprehensive as Racket match,
pcase is a frequently-used subset.)

For another example, although I wish it were named filter, I can use
cl-remove-if-not from the standard cl-lib package. I feel I ought to
know it exists, and if I do, I may as well just use it?


2. I think the desired trade-offs can be different. For example in
Clojure if I rename a function, the old definition still exists under
the old name, ready to cause confusion. That's "too dynamic" for my
taste, outside Emacs. But that dynamism is part of what makes the
Emacs environment special. And anyway most (of my) Elisp code is doing
tactical UX grunt work. So the cost:benefit seems different.


3. My impression is that there's been somewhat of an Emacs renaissance
the last few years. Probably due to the new package manager, as well
as a cohort of fresh packages like dash.el from new, younger folks.

That entire "ecosystem" is what makes Emacs special, I think. Before
embarking for real on a new project, not only does there need to be a
story about supporting that, I think it would need to be totally
seamless. Which is maybe not impossible but probably non-easy.

[William G Hatch]

I would also love to see a new emacs based on Racket. Is rmacs by Tony
Garnock-Jones intended to be a small project or is he meaning for it to
grow to be a serious contender with emacs, vim, etc?

I agree with Greg that the ecosystem and momentum around emacs is its
strongest point. I've written a couple small emacs packages, and in
doing so I added myself to the watch list of the Melpa emacs package
repository, and they probably average about 3 new packages per day. So
rmacs would need a lot of momentum to be able to get many users. But I
would love it. Just as long as doesn't try to throw out things like
multiple frontends (IE runnable in both terminal and as an X window),
and extensibility everywhere. (It's reasons like these that I believe
Atom, Sublime, etc will never seriously compete)

[Tony Garnock-Jones]

On 07/03/2015 01:11 PM, William G Hatch wrote:
> I would also love to see a new emacs based on Racket. Is rmacs by Tony
> Garnock-Jones intended to be a small project or is he meaning for it to
> grow to be a serious contender with emacs, vim, etc?

At the moment, it's just for my own edification. My aim is to get it
into suitable shape for me to use it for day to day editing, and then
see how I go.

Currently missing before that becomes the case (using
https://en.wikipedia.org/wiki/MoSCoW_method):
M - move by words
M - move by s-expression structure
S - syntax highlighting for Racket code (half-implemented)
C - something dired-ish
C - isearch (ordinary search and regexp-search is already there)

I want to explore it as a way of getting a Racket REPL on steroids. I
imagine firing up Racket, getting a deceptively normal-looking
terminal-style REPL, working for a bit (with rich, full-emacs-style
functionality available at the REPL), and then deciding "no, I want a
fullscreen editor", pressing a hotkey, and "promoting" the REPL into a
full rmacs session with multiple windows, buffers etc.

I want to explore some of the CLIMish "presentation" ideas for the REPL.

I'm also interested in reloading/hot-swapping of code and state. I've
been experimenting with this for web apps [1] and it'd be interesting to
support it as part of the IDE-like functionality in rmacs.

HOWEVER, I'm a PhD student and all this depends on what little spare
time I find for it.

Shorter me: it's a small hobby project ;-)

Tony

[1] https://github.com/tonyg/racket-reloadable#readme

[Neil Van Dyke]

Tony Garnock-Jones wrote on 07/03/2015 03:15 PM:
> I want to explore it as a way of getting a Racket REPL on steroids. I
> imagine firing up Racket, getting a deceptively normal-looking
> terminal-style REPL, working for a bit (with rich, full-emacs-style
> functionality available at the REPL), and then deciding "no, I want a
> fullscreen editor", pressing a hotkey, and "promoting" the REPL into a
> full rmacs session with multiple windows, buffers etc.

Kickbottom! This is the kind of cool power-user thing that we love to
encounter in platforms.

For your line-oriented terminal mode, please consider supporting
multi-line-editing/indenting/coloring (without going full-screen):
http://lists.racket-lang.org/dev/archive/2014-December/014894.html

Neil V.