[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: "Bringing GNU Emacs to Native Code" at the European Lisp Symposium
From: |
Andrea Corallo |
Subject: |
Re: "Bringing GNU Emacs to Native Code" at the European Lisp Symposium |
Date: |
Mon, 04 May 2020 10:07:34 +0000 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) |
Richard Stallman <address@hidden> writes:
> [[[ To any NSA and FBI agents reading my email: please consider ]]]
> [[[ whether defending the US Constitution against all enemies, ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
> > This the point. I think we could at best make this assumption only on
> > calls to C primitives (that we assume cannot be redefined) that are
> > known to be side effect free and not to use global variable bindings in
> > general. Any other call must have all variables spilled first.
>
> You're concerned about the possibility of redefining Lisp functions
> defined in other files, and that the new function definitions might
> touch variables bound in your file.
Also in the same file. The native compiler as the byte-compiler can
compile files as a whole or single functions too. If one of these gets
redefined the assumptions used to compile all the others could become
wrong.
I suspect the assumption in discussion would be too weak and likely to
cause bugs that are very difficult to track down.
> I think it is legitimate to compile assuming they don't do that. How
> about seeing where you can get, that way?
>
> > Given the discussed
> > suspect of poor performance I intentionally left this task aside to work
> > on more urgent tasks. Nothing prevents to have a try on this later if
> > we think is really important.
>
> That seems right to me. I am not saying this particular issue is urgent.
> Only that it should get done by and by.
_I'm in favor_ of giving dynamic scope compilation a shot on day and see
how it runs (with the right prioritization). But I'm not in favor of
designing and implementing complex passes that are dynamic scoped code
specific, especially if based on dangerous assumptions.
Is my believe that there are other tasks inside the compiler but also
outside of it in Emacs that deserves sooner man power I'd like to help
with. This is just my optinion obviously.
Regards
Andrea
--
address@hidden
- Re: "Bringing GNU Emacs to Native Code" at the European Lisp Symposium, Richard Stallman, 2020/05/01
- Re: "Bringing GNU Emacs to Native Code" at the European Lisp Symposium, Richard Stallman, 2020/05/01
- Re: "Bringing GNU Emacs to Native Code" at the European Lisp Symposium, Andrea Corallo, 2020/05/02
- Re: "Bringing GNU Emacs to Native Code" at the European Lisp Symposium, Richard Stallman, 2020/05/02
- Re: "Bringing GNU Emacs to Native Code" at the European Lisp Symposium, Stefan Monnier, 2020/05/03
- Re: "Bringing GNU Emacs to Native Code" at the European Lisp Symposium, Richard Stallman, 2020/05/03
- Re: "Bringing GNU Emacs to Native Code" at the European Lisp Symposium, Stefan Monnier, 2020/05/04
- Re: "Bringing GNU Emacs to Native Code" at the European Lisp Symposium, Richard Stallman, 2020/05/04
- Re: "Bringing GNU Emacs to Native Code" at the European Lisp Symposium, Stefan Monnier, 2020/05/04
- Re: "Bringing GNU Emacs to Native Code" at the European Lisp Symposium,
Andrea Corallo <=
Re: "Bringing GNU Emacs to Native Code" at the European Lisp Symposium, Stefan Monnier, 2020/05/02