emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: scratch/accurate-warning-pos: Solid progress: the branch now bootstr


From: Alan Mackenzie
Subject: Re: scratch/accurate-warning-pos: Solid progress: the branch now bootstraps.
Date: Tue, 27 Nov 2018 21:53:47 +0000
User-agent: Mutt/1.10.1 (2018-07-13)

Hello, Paul.

On Tue, Nov 27, 2018 at 13:37:29 -0800, Paul Eggert wrote:
> On 11/27/18 1:15 PM, Alan Mackenzie wrote:
> > Anyhow, as far as creating a better solution than
> > scratch/accurate-warning-pos goes, have you had any further thoughts?

> Hash tables for cons locations would work well enough, if someone had 
> the time to put into it.

I don't think they would.  Macros would mess things up.  For example,
after expanding a macro like the contrived

   (defmacro dehash (form)
     (copy-tree form))

, how would the recorded cons locations be linked up with the resulting
form?

> The main objection seems to be that the byte-compiler would lose track
> of location information. But we can fix the byte-compiler so that it
> doesn't lose track of the location information. That's purely a
> byte-compiler issue, which is a good thing for software engineering
> reasons as well as for performance reasons.

I don't think this is right.  See above.

> > I've thought about the double interpreter idea, and must confess I've no
> > idea how one might go about implementing it in any reasonable time.

> There's a simpler way to do a double interpreter. Use a compile-time 
> test to decide whether eq operates slowly. Build two copies of Emacs, 
> the slow one and the fast one, by compiling the slow one with -DSLOW_EQ 
> (or whatever). Use the slow Emacs to byte-compile Emacs (and any other 
> program that wants to be byte-compiled); this will output nicer 
> diagnostics. Use the fast Emacs for everything else.

> I'm not saying I *like* this solution (I don't). But it would address 
> the problem of poor diagnostic locations when building Emacs, and it 
> shouldn't slow Emacs down one bit in ordinary use.

Of course, the "slow" Emacs would somehow need to be used by the byte
compiler after Emacs has been built, to continue to get accurate warning
locations.  I don't like this approach either.  ;-)

-- 
Alan Mackenzie (Nuremberg, Germany).



reply via email to

[Prev in Thread] Current Thread [Next in Thread]