Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Continued progress porting Emacs to Rust

db48x.net

Post reply on HN
Print view View original

41–50 of 60 posts

Re: Continued progress porting Emacs to Rust

#41

Post by ealhad »

lispm wrote: post #34
ealhad wrote: post #26

Earlier quoted context omitted.

> My only wish is that emacs were written in an even better language than elisp (like Common Lisp) There are a lot of bad things in CL too, unfortunately. I wonder if a Lisp will become really popular in the near future. Maybe Racket?

There are 'bad things' in any programming language. Common Lisp is actually quite a bit more advanced out of the box than Emacs Lisp: lexical binding, excellent error handling, good support for compilation, extensive object-oriented features, it has multiple implementations with independet code bases, implementations with threading, ... CL has been used to develop Emacs editors already. But the thing is a non-starter…

Of course CL is more advanced than Emacs Lisp, it's a very interesting platform! I have grown tired of some of its aspects though, like those endless lists of possible keyword arguments.

But this is just me nitpicking about elegance.

Re: Continued progress porting Emacs to Rust

#42

Post by db48x »

danaliv wrote: post #37
db48x wrote: post #30

Earlier quoted context omitted.

You are entirely correct, and I should perhaps have been more precise. However, because Lisp_Objfwd is basically a pointer, zero-initialized is pretty much as good as uninitialized. It's not a useful value.

It fails a NULL check, where an uninitialized value (probably) won’t. That seems like a pretty important distinction, no?

In C, yes, that's a useful distinction. One of the goals of Rust is that you'll never have to check that manually. You'll never encounter a pointer that points to an invalid, uninitialized, or unallocated object. Since we're writing some unsafe code here, we can operate outside that restriction as long as we promise to put things right before the end of the unsafe block. This can be simplified somewhat once everything is written in Rust.

Re: Continued progress porting Emacs to Rust

#43

Post by db48x »

beagle3 wrote: post #38
db48x wrote: post #30

Earlier quoted context omitted.

You are entirely correct, and I should perhaps have been more precise. However, because Lisp_Objfwd is basically a pointer, zero-initialized is pretty much as good as uninitialized. It's not a useful value.

The C spec says zero in a pointer context is null (and the other way around) Can you elaborate on “as good as uninitialized”?

You can't ever usefully dereference a null pointer, so the only thing you can safely do with it is check to see if it is null. I commented on a sibling comment in more detail, but basically in Rust no reference is allowed to be null except temporarily inside an unsafe context.

Re: Continued progress porting Emacs to Rust

#44

Post by db48x »

mrec wrote: post #12

Not an Emacs user, so forgive me if I'm being dense, but is this (from the README) really true? Emacs will change how you think about programming. Emacs is an incremental programming environment. There's no edit-compile-run cycle. There isn't even an edit-run cycle. You can execute snippets of code and gradually turn them into a finished project. There's no distinction between your editor and your interpreter. I'm as…

The more usual statement is that learning Lisp will change how you think about programming. Many have said that it will expand your frame of reference, and make you a better programmer in whatever other languages you end up using. I agree with them, and also that having a programming language so easily accessible inside your editor is also similarly liberating. You can decide that your editor can work more efficiently in some way, then take a few minutes to extend how your editor works, and then continue on with your original task.

As languages go, I would say that Forth and Prolog also have this quality of expanding your frame of reference.

Re: Continued progress porting Emacs to Rust

#45

Post by db48x »

lispm wrote: post #34
ealhad wrote: post #26

Earlier quoted context omitted.

> My only wish is that emacs were written in an even better language than elisp (like Common Lisp) There are a lot of bad things in CL too, unfortunately. I wonder if a Lisp will become really popular in the near future. Maybe Racket?

There are 'bad things' in any programming language. Common Lisp is actually quite a bit more advanced out of the box than Emacs Lisp: lexical binding, excellent error handling, good support for compilation, extensive object-oriented features, it has multiple implementations with independet code bases, implementations with threading, ... CL has been used to develop Emacs editors already. But the thing is a non-starter…

Anyone who has seriously proposed porting Emacs to any language will have made plans to support running the existing Elisp code without modification. You can easily write an Elisp compiler in Common Lisp.

In fact, the original Lisp machine eventually supported Common Lisp as well as the original Lisp Machine Lisp. You could write any individual function in either language, and call from one to the other transparently.

Re: Continued progress porting Emacs to Rust

#46

Post by lispm »

rauhl wrote: post #39
lispm wrote: post #34

Earlier quoted context omitted.

There are 'bad things' in any programming language. Common Lisp is actually quite a bit more advanced out of the box than Emacs Lisp: lexical binding, excellent error handling, good support for compilation, extensive object-oriented features, it has multiple implementations with independet code bases, implementations with threading, ... CL has been used to develop Emacs editors already. But the thing is a non-starter…

Emacs Lisp has lexical binding these days. I’d like to see an Emacs with a Common Lisp core, and an elisp execution engine to run all the legacy elisp code. https://github.com/blindglobe/clocc/blob/master/src/cllib/el... looks like a decent first start, although it supports an older version of elisp. Someday if I have the free time I’d love to spend time working on such a thing. Maybe when I’m retired!

> Emacs Lisp has lexical binding these days

sure, but you need to support legacy software, too. Which is most Emacs Lisp ever written.

Re: Continued progress porting Emacs to Rust

#47

Post by lispm »

db48x wrote: post #45
lispm wrote: post #34

Earlier quoted context omitted.

There are 'bad things' in any programming language. Common Lisp is actually quite a bit more advanced out of the box than Emacs Lisp: lexical binding, excellent error handling, good support for compilation, extensive object-oriented features, it has multiple implementations with independet code bases, implementations with threading, ... CL has been used to develop Emacs editors already. But the thing is a non-starter…

Anyone who has seriously proposed porting Emacs to any language will have made plans to support running the existing Elisp code without modification. You can easily write an Elisp compiler in Common Lisp. In fact, the original Lisp machine eventually supported Common Lisp as well as the original Lisp Machine Lisp. You could write any individual function in either language, and call from one to the other transparently…

> You can easily write an Elisp compiler in Common Lisp

I have no idea how easy it is and I have seen no attempt to do that (running the existing Elisp code without modification on top of a CL runtime). If it would be easy, I'd expect it to be done already.

The https://www.cliki.net/CL-Emacs page seems to of no help...

Do you know of any attempt demonstrating how easy it actually is?

> In fact, the original Lisp machine eventually supported Common Lisp as well as the original Lisp Machine Lisp. You could write any individual function in either language, and call from one to the other transparently.

That was a major engineering effort - putting both languages side by side onto a single runtime.

Re: Continued progress porting Emacs to Rust

#48

Post by lispm »

ealhad wrote: post #41
lispm wrote: post #34

Earlier quoted context omitted.

There are 'bad things' in any programming language. Common Lisp is actually quite a bit more advanced out of the box than Emacs Lisp: lexical binding, excellent error handling, good support for compilation, extensive object-oriented features, it has multiple implementations with independet code bases, implementations with threading, ... CL has been used to develop Emacs editors already. But the thing is a non-starter…

Of course CL is more advanced than Emacs Lisp, it's a very interesting platform! I have grown tired of some of its aspects though, like those endless lists of possible keyword arguments. But this is just me nitpicking about elegance.

Richard Stallman doesn't like that either. There is no support from him for a CL version. There never was. It's nothing the core developers of GNU Emacs are interested in.

But if we look around - most alternatives have their variants of keyword alternative mechanisms.

Racket: https://docs.racket-lang.org/guide/lambda.html

Guile: https://www.gnu.org/software/guile/manual/html_node/Coding-W...

Chicken Scheme: https://wiki.call-cc.org/man/4/Extensions%20to%20the%20stand...

Re: Continued progress porting Emacs to Rust

#49

Post by kazinator »

tom_mellior wrote: post #20

The author misunderstands some parts of the C language, in particular related to static variables. "In fact, these aren't just file globals accessible to only one translation unit, these are static variables that are accessible across the whole program." gets the meaning of C's static exactly backwards: C file-scope static variables are only accessible (by name) in their translation unit; all other file-scope variabl…

> gets the meaning of C's static exactly backwards

Which one? It has multiple.

First, there is storage duration:

C99 6.2.4 "There are three storage durations: static, automatic, and allocated."

Variables with external linkage defined at file scope are static in the sense that they have static storage duration; it is not incorrect to call them static variables, though a bit unusual. If they have external linkage, it's more common just to call them globals.

The static storage class specifier keyword used at file scope causes a name to have internal linkage. In a block scope, it requests the above static storage duration.

Re: Continued progress porting Emacs to Rust

#50

Post by kazinator »

db48x wrote: post #43
beagle3 wrote: post #38

Earlier quoted context omitted.

The C spec says zero in a pointer context is null (and the other way around) Can you elaborate on “as good as uninitialized”?

You can't ever usefully dereference a null pointer, so the only thing you can safely do with it is check to see if it is null. I commented on a sibling comment in more detail, but basically in Rust no reference is allowed to be null except temporarily inside an unsafe context.

There isn't anything you can do safely with an actually uninitialized value, though.

In the internals of TXR Lisp, I used a null pointer to represent the symbol nil, with all the useful semantics that follows. If an object containing Lisp values is initialized to zero, those values are nil.

Post reply on HN