Remacs: Why not write emacs all in elisp? I mean, make elisp self-booted

Created on 6 Oct 2018  Â·  6Comments  Â·  Source: remacs/remacs

While Rust and C both have to be converted into AST(Abstract Syntax Tree), Lisp itself is just AST.

In fact, I can't see any difference between Rust and C while I have to configure emacs in elisp.

And the best method of propagating emacs is not translating it from C to Rust, but to Make Elisp Greater than Python/C/Go/PHP/Powershell/C#/CommonLisp/Scheme/Rust and then Defeat the Ecosystem of Java/Javascript, Invade the Zone of verilogHDL/VHDL.

As an expression of AST, Lisp have the natural capacity to complete missions above, and should have done these. So what makes missions fail? People splitting up.

All 6 comments

Misih ragu

Yeah.
Why just not extend ELisp, until it is not ELisp - until it is Math. And then solve and rewrite this Universe, or better - create new better Universe.

Thanks for your feedback! You might enjoy the links in the fork section of our readme that discusses other elisp implementations. El Compilador is indeed exploring self-hosting elisp.

I'm afraid this isn't a goal of the Remacs project though.

El Compilador:"The compiler can now generate C code that can be compiled as part of Emacs"

That's not the goal, "Self-booted" usually means that there is only one language needed except assembly codes.

I know elisp have many features that is creepy, compared with these new programming language, but the condition won't change without core problems being solved.

Thank you for the reply. Maybe the topic I wrote can cause your interest: https://zhuanlan.zhihu.com/c_156166721

ds_rds

"The syntax is "abstract" in the sense that it does not represent every detail appearing in the real syntax, but rather just the structural, content-related details."
It meant that structure is imperative and AST is abstract representation.

Our CPUs are built on transistor matrix logic, they can not operate pure Lambda calculus.
That is why languages with imperative paradigms can be more optimized to CPU, than Lambda calculus.

Since ELisp is not purely functional and allows imperative approach - its core code itself, and code written in it - is mix of both, functional and imperative.

Because Lambda calculus not lays on PC architecture too well - code generated from Lisp to C - newer going to approach the most optimized C code for PC architecture.

You can generate C code - it would not be the most optimized code. And generator is probably would not produce bug-free C code.

Beta reduction and approaching Beta normal form with pure functions can cause great simplification of algorithms. But once more Lambda expressions is in need to be translated to current machine code. Which can not be made bug-free, requires imperative language, and facing reality bounds.

So the answer to your requirement is - build a CPU that operates in Lambda expressions, and write Lisp in a pure approach. Then we can talk deal.

So CPUs are not pure functional.
And AST is not pure.
Assembly is imperative as it gets.
ELisp is a mix.

To make language self-booted is a good idea.
ELisp needs to migrate to higher-order functions, before implementing self-boot. If my simple view is enough.

Nobody touched that C code in years, guys are doing Labour of Hercules: Augean stables. They would clean-up the core code, which would bring us all closer to evolve Emacs and ELisp, and extend ELisp, make it self-booted would be easier. Rust is much better language for refactoring.

@Anton-Latukha
I posted the image above, which is to say that there is difference between "function" and "state machine", so that the concepts of "pure functional language" and "Lambda expressions" don't make problems clean

As a kind of RDS( Runnable Data Structure), a good programming language should simplify many unnecessary tricks, and make real problems clean.

I think that lisp-style meets the request.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

rlupton20 picture rlupton20  Â·  5Comments

brotzeit picture brotzeit  Â·  5Comments

MarcusE1W picture MarcusE1W  Â·  5Comments

ZelphirKaltstahl picture ZelphirKaltstahl  Â·  4Comments

raxod502 picture raxod502  Â·  4Comments