Emacs Lisp's Future • Hacker News Board

Re: Emacs Lisp's Future

#141

Post by tedks » Wed, Sep 17, 2014, 9:14 PM UTC

wtbob wrote: post #121

tedks wrote: post #114

Earlier quoted context omitted.

As I said in my comment, >Guile can run elisp already Guile already interprets Elisp. Elisp can run unmodified on Guile. Guile, the virtual machine, contains a front-end for Emacs Lisp. المكر ينفذ أصلا إيماكس اللثغة. Guile jatorriz exekutatzen emacs Lisp. It is true there are no compatibility issues because Guile is an implementation of Emacs Lisp.

From the same thread https://lists.gnu.org/archive/html/emacs-devel/2014-09/msg00... > It's not a 100% drop-in replacement, that's true…(eq foo t) should always work. (eq foo nil) will only work if that `nil' came from Elisp code; if it's a Scheme #f or '() in disguise, then you need to make that (not foo) or (null foo) (both works in both cases); anything but (eq foo nil).

That seems to imply that the problem is in the Scheme/Elisp interface, not in Guile's execution of pure Elisp.

Re: Emacs Lisp's Future

#142

Post by taylanub » Wed, Sep 17, 2014, 10:07 PM UTC

e40 wrote: post #112

lispm wrote: post #95

Earlier quoted context omitted.

Wouldn't it be nice when Emacs would not be blocked when some Lisp routine runs? Lots of people have written excellent code for GNU Emacs, but the implementation runtime hasn't improved that much.

Wouldn't it be nice when Emacs would not be blocked when some Lisp routine runs? Yes, it would be nice, but can you imagine the bugs that will happen while everyone works out the details of how to do it properly?

Even in the current pre-alpha/alpha stage of Guile-Emacs, I can launch a thread from Scheme, do work, return to the main thread, then call an Elisp function on my result. (Scheme and Elisp data types are unified.) No bugs or unpleasant details there.

Calling Elisp functions and accessing Emacs data types (buffers, windows) from multiple threads is another issue; if you don't want to bother with it then don't; you still get all the other benefits of being on Guile. (Calling to any Guile module agnostically as if it were an Elisp library (including, say, Guile's OpenGL module), having an FFI, getting JIT or AOT native compilation in the future, etc.)

Re: Emacs Lisp's Future

#143

Post by taylanub » Wed, Sep 17, 2014, 10:09 PM UTC

yason wrote: post #8

Given all the reworks of software projects that have a) been started b) then delayed c) then delayed more, "because this time we'll make it perfect" and d) then failed to gather traction because of incompatibilities, it's my humble guess that the only way would be to continue ELisp as it is and slowly rework the compiler/interpreter and the runtime into a more modern codebase, and add missing features such as thread/…

Guile-Emacs is not a rework, it's a rebase. It already runs all Elisp, sans bugs and (currently severe) performance regressions. It will be a nearly-drop-in replacement, a new version of GNU Emacs, even less different from it than XEmacs. In general, it will only add to Emacs, and change the underlying implementation of Elisp.

Re: Emacs Lisp's Future

#144

Post by taylanub » Wed, Sep 17, 2014, 10:11 PM UTC

wtbob wrote: post #121

tedks wrote: post #114

Earlier quoted context omitted.

As I said in my comment, >Guile can run elisp already Guile already interprets Elisp. Elisp can run unmodified on Guile. Guile, the virtual machine, contains a front-end for Emacs Lisp. المكر ينفذ أصلا إيماكس اللثغة. Guile jatorriz exekutatzen emacs Lisp. It is true there are no compatibility issues because Guile is an implementation of Emacs Lisp.

From the same thread https://lists.gnu.org/archive/html/emacs-devel/2014-09/msg00... > It's not a 100% drop-in replacement, that's true…(eq foo t) should always work. (eq foo nil) will only work if that `nil' came from Elisp code; if it's a Scheme #f or '() in disguise, then you need to make that (not foo) or (null foo) (both works in both cases); anything but (eq foo nil).

Note that using the `not' and `null' functions instead of comparing equality to `nil' is good coding style anyway.

Re: Emacs Lisp's Future

#145

Post by belorn » Wed, Sep 17, 2014, 10:13 PM UTC

mwfunk wrote: post #11

__david__ wrote: post #7

Earlier quoted context omitted.

There's no way they'd do that. There's a rift because of LLVM's licensing philosophy: https://gcc.gnu.org/ml/gcc/2014-01/msg00247.html

The fact that he even uses the term "adversaries" in this post is disheartening. It's really disappointing that someone who could potentially be such a force for good in the world gets derailed by what is basically tribalism. Two parties can disagree on 99% of their beliefs, yet still find ways to come together on the 1% that they happen to agree on. These parties can work together to each others' mutual benefit, and…

What you are calling for is Argument to moderation[1]. Its a common fallacy, which asserts that the truth can be found as a compromise between two opposite positions. Working towards a goal without compromise with those who actively make that goal harder is not wrong.

When I have seen RMS labelled people as the "Others", it been when someone has done actions that is direct detriment to free software. If your goal is to build something, and someone else comes with a hammer and start tearing it down, I will give you some permission to be annoyed.

[1]: https://en.wikipedia.org/wiki/Argument_to_moderation

Re: Emacs Lisp's Future

#146

Post by taylanub » Wed, Sep 17, 2014, 10:15 PM UTC

eschulte wrote: post #69

HerrMonnezza wrote: post #43

Tom Tromey started an automated rewrite of Emacs in Common Lisp in 2012, see the announcement at: http://tromey.com/blog/?p=709 I couldn't find any progress report after http://tromey.com/blog/?p=751 so I guess the project has been abandoned early.

I think this is the most realistic approach mentioned here, and tromey is actually familiar with the Emacs internals.

So is BT Templeton, the person who has been hacking away at Guile-Emacs GSoC after GSoC. :-)

(They seem very skilled, don't be fooled by the fact that it's GSoC; no idea what the skill level of people who take part in that usually tends to be.)

Re: Emacs Lisp's Future

#147

Post by belorn » Wed, Sep 17, 2014, 10:21 PM UTC

Blackthorn wrote: post #104

belorn wrote: post #34

Earlier quoted context omitted.

If people could ensure that no one would restrict how others uses the program, having GPL'ed software released under BSD would not be an issue. A bsd project could simply add to the license that people should not use patents, legal threats, or hardware tricks in order to restrict people, and I would see that as equivalent as making the whole work under the GPL. The BSD license itself is not a problem, but people who…

BSD products cannot use GPL code without changing the entire license of the product. That means there is no way that BSD products can use GPL code.

If they must enable those who want to add restriction to the BSD product, then they can't use GPL licensed code.

If they don't care about enabling proprietary model for the product, then they can just continue license their code as BSD and combine that with the GPL licensed code. Distributors will have to abide to both licenses, but that is not a problem so long they do not try start a proprietary model or tries enable other to do it.

Re: Emacs Lisp's Future

#148

Post by taylanub » Wed, Sep 17, 2014, 10:26 PM UTC

muuh-gnu wrote: post #10

Blackthorn wrote: post #9

Earlier quoted context omitted.

Literally dozens more. Look, neither Common Lisp nor any Scheme implementation are exactly topping the charts in popularity these days. This should be about the technical merits of the choice, because I'm pretty sure Emacs Lisp both has more code and more programmers (both represented in the forms of small scripts we've shoved into scratch and evaluated) than both.

The decision to go either Common Lisp or Scheme was made based on RMS very personal reasons and conflicts with close-source Lisp machine companies during the first half of the 80s. GNU has had two common Lisp implementations under their umbrella at least since mid 90s (CLISP (of Viaweb fame) and GCL (of Maxima fame)), but due to RMS' hate of Symbolics and Common Lisp, all of the effort was invested into making Guile…

You're talking out of ignorance, keep it down.

Guile-Emacs runs Elisp, not Scheme, and Elisp will remain the main Emacs language for a long time. Using Scheme will become a possibility and you can bet on some people starting it immediately, but nobody is forced.

Guilifying Emacs is not "pushed by the Guile guys," it's always been RMS's desire.

The "Emacs guys" is a rather large group of people, which is essentially a superset of "Guile guys." Some of them would love Scheme, others wish it was CL instead, others want to take Elisp on its own path to evolution. Guile offers an evolved Elisp, and Scheme as an addition. And of course One Day someone might sit down and implement CL for Guile too, you never know.

GCC, GDB, GNU Make, and some other tools can be extended in Guile. The Nix-derived package manager Guix which forms the core of the upcoming official GNU distribution is also written in Guile. It's becoming quite "relevant" on its own terms. But sure, Emacs would be a huge boost. They're both GNU software so it's a logical come-together if you ask me.

Re: Emacs Lisp's Future

#149

Post by quotemstr » Wed, Sep 17, 2014, 10:56 PM UTC

lispm wrote: post #94

riffraff wrote: post #87

can someone more knowledgeable than me explain how is elisp closer to CL than to Scheme?

Both Emacs Lisp and Common Lisp are coming from MIT's Maclisp dialect. There were Emacs variants written in Maclisp or its dialects before GNU Emacs existed. Emacs Lisp was a very simplified Maclisp. Common Lisp modernized Maclisp (especially lexical binding), preserved a lot of Maclisp features and standardized stuff like an Object System (CLOS), error-handling (Conditions), enhanced argument lists (especially keywo…

Keyword argument support is in the Emacs core these days, along with the rest of the CL library.

    (require 'cl-lib)
    (cl-defun foo (&key a b c) (list a b c))
    (foo :c 3 :b 4 :a 1)

Re: Emacs Lisp's Future

#150

Post by bane » Wed, Sep 17, 2014, 11:13 PM UTC

belorn wrote: post #137

dragonwriter wrote: post #131

Earlier quoted context omitted.

> In order to enforce any liberty, coercion is the only way available to do so. Sure, "enforce" implies "coercion". That doesn't imply that coercion is the only way to acheive liberty.

Please try define a freedom which do not need coercion of someone in order to enforce it. I defy that any such thing could exist. If you want freedom of speech, you have to prevent those who would seek out to squelch it. Freedom of the press is only possible by preventing those who would otherwise burn down the printing press. Freedom of person prevents assassins and rapists from doing their ill deeds, and has to be…

Well that's disingenuous. You specifically brought up that the GPL is a non-coercive agent for freedom. Now that we've demonstrated that it is coercive, you moved your fence posts.

You're really tied up in the the history of liberty and freedom, and act like it the matter is all tied up and resolved. But very little could be further from the truth!

Even more important, you keep attempting to draw parallels to enlightenment thought on freedom, when the modern thought on the matter has come a long way since then and to anybody who seriously studies all of the eras of liberal thinking, the GPL is not a particularly interesting or conforming philosophy.

It parallels totalitarian philosophies far more easily than any democratic of liberal thinking on the matter. A country based around the kind of self-perpetuation at all costs kind of philosophy the GPL is built around would be a dystopia.