[Top][All Lists]

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

Re: scratch/accurate-warning-pos: next steps.

From: Eli Zaretskii
Subject: Re: scratch/accurate-warning-pos: next steps.
Date: Tue, 11 Dec 2018 08:41:00 +0200

> Date: Mon, 10 Dec 2018 21:03:10 +0000
> Cc: address@hidden
> From: Alan Mackenzie <address@hidden>
> > > That would mean starting the byte compilation with no position
> > > information being gathered, and then when an warning occurs, aborting
> > > the compilation and starting again from scratch with the position
> > > information being gather and alternative interpreter being used.
> > Not necessarily.  It could mean invocation of a special code whose
> > goal is to find the position of an error in a given form.  The
> > position of the beginning of this form will have been known, as AFAIU
> > the existing byte compiler does collect that, or has means to
> > determine that.
> We know the position of the beginning of the form, yes.  We need some way
> of determining the source position of a symbol, cons, or vector on the
> inside of this form.
> The traditional alist of symbols and positions is one way, and it no
> longer works well (if it ever did).  Symbols with position is another
> way, which appears to work well, in spite of the complexity.
> You seem to be proposing a third way, but without giving away any
> details.

I don't have any details, just an idea.  I hope it could be helpful,
because implementing it would side-step all the problems you
discovered with the other approaches:

  . it doesn't slow down the Lisp interpreter
  . it doesn't slow down byte compilation when there are no
    errors/warnings to report
  . it probably doesn't require introduction of new low-level
    facilities, like annotating symbols with positions or redirecting
    Lisp subroutines to alternative versions

> I'm not sure how this special-purpose code would work.  Say we find an
> error or warning involving symbol foo as the car of some form, I can't
> see any way of determining its source position that doesn't involve going
> back to the position of the beginning of the form, and slogging through
> the form, somehow.

Yes, I was proposing something like that.  Why is that a problem?

> Maybe, rather than reading the form, we could scan it a token at a time,
> storing it in, say vectors, rather like a traditional non-lisp compiler
> does.  But this is hardly attractive, and would be a LOT of work.

I'm not sure why is it less attractive than the other alternatives.
But if my idea doesn't sound helpful, feel free to disregard it.

reply via email to

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