Re: Thoughts on getting correct line numbers in the byte compiler's warning messages

[Stefan Monnier]

> Actually this idea was not good;

[ I'll assume you're not talking about the idea of using such a reader in
  edebug, but about using such a reader for your use case.  ]

> macros could not handle such a form without severe changes in the way
> macros work.  (A research project, perhaps).

Right.  The way I was thinking about it was that when calling
macros we'd do something like:

    (plain-to-annotated
     (macroexpand (annotated-to-plain sexp)))

not a research project by any stretch, but its impact on performance
could be a problem, indeed.

> The reader would produce, in place of the Lisp_Objects it currently
> does, an object with Lisp_Type 1 (which is currently unused).  The rest
> of the object would be an address pointing at two Lisp_Objects, one
> being the "real" read object, the other being a source position.

More generally, you're suggesting here to add a new object type (could
just as well be a new pseudo-vector or any such thing: these are just
low-level concerns that don't really affect the overall design).

> The low level routines, like CONSP, and a million others in lisp.h would
> need amendment.

So you're suggesting to change the low-level routines accessing
virtually all object types to also accept those "annotated objects"?

That means all processing of all objects would be slowed down.
I think that's a serious problem (I'd rather pay a significant slow
down in byte-compilation than a smaller slowdown on everything else).

> But the Lisp system would continue with 8-byte objects,
> and the higher level bits (nearly all of it) would not need changes.
> The beauty of this scheme is that, outside of byte compilation, nothing
> else would change.

Also, I wonder how this (or any other of the techniques discussed) solve
the original problem you describe:

    The forms created by the reader go through several (?many)
    transformative phases where they get replaced by successor forms.
    This makes things more difficult.

E.g. we could implement big-object as

    (defun big-object (object location)
      (cons object location))
or
    (defun big-object (object location)
      (puthash object location location-hash-table)
      object)
or
    (defun big-object (object location)
      (make-new-special-object object location))

but the problem remains of how to put it at all the places where we need it.

> The extra indirection involved in these "big objects" would naturally
> slow down byte compilation somewhat.  I've no idea how much, but it
> might not be much at all.

Indeed, I don't think that's a significant issue.


        Stefan