[wg-camlp4] About 'a loc in the Parsetree

[Gabriel Scherer]

I think the bin-annot code is recent enough (sic) to be changed
without worries as long as you maintain the feature set.
I would suspect the addition of 'a loc were directed by the needs of
existing tools making use of identifier information (.annot and
ctags/browserish prototypes), with the understanding to add more later
if needed.

Adding locations to the missing places, and removing them where
they're redundant seems the right thing to do, and we'd better do it
sooner than later.

(How good is your coverage of the existing codebase, in the
distribution, that depends on the parsetree and typedtree structure?
There is Camlp4 of course, and in this case I think you could easily
make it compatible to your changes. I am a bit more worried about the
not-clearly-defined stuff that was added with bin-annot, (printing
typedtree and stuff), some of which in tools/, some in other places,
that I'm not sure are all exercised or even compiled by the usual
"make world.opt" drill.)

On Thu, Apr 4, 2013 at 2:58 PM, Alain Frisch <alain.frisch at lexifi.com> wrote:
> Dear all (caml-devel + wg-camlp4),
>
> I'd like to discuss the use of the 'a loc type (string loc and
> Longident.loc) in the definition of the Parsetree.  I think this type was
> introduced as part of the "binannot" project, in order to keep more location
> information in the Typedtree, to be used by external tools reading .cmt
> files.
>
> First, some "unlocated" identifiers remain in the Parsetree
> (cf Ptyp_var, Ptyp_alias, Ptyp_poly, Pfield, Pexp_send, Pexp_newtype,
> Pctf_val, Pctf_virt, Pctf_meth, Pcf_inher).  I assume this is simply an
> oversight. Or is there any deeper reason for keeping locations for some
> identifiers but not all of them?
>
> Second, some locations are redundant for constructions whose syntax is just
> the identifier (Ppat_var, Pexp_ident, Pmty_ident, Pmod_ident).  The same
> location is store in the 'a loc record and in pexp_loc/ppat_loc/etc field.
> I guess that the rationale is that some imaginary alternative concrete
> syntax for the language would use a different representation for those
> constructions.  Another argument is uniformity of representation.  But those
> redundant location introduce some overhead when building and deconstructing
> very common fragments of Parsetrees. For building fragments, this can be
> largely accommodated by the use of constructor functions, but for pattern
> matching on AST, there is no such easy solution.  One could consider getting
> rid of those redundant "'a loc" wrappers.  Any opinion on this topic?
>
>
> Alain
>
> _______________________________________________
> wg-camlp4 mailing list
> wg-camlp4 at lists.ocaml.org
> http://lists.ocaml.org/listinfo/wg-camlp4