[erlang-patches] Return end locations in erl_scan

Vlad Dumitrescu <>
Wed Mar 20 14:06:07 CET 2013


Hi,

The multiline elements could be handled with the help of an utility that
given a string and a (starting) position can compute the end position. I
would hope that the implementation already has it in one form or another.

regards,
Vlad



On Wed, Mar 20, 2013 at 2:00 PM, Anthony Ramine <> wrote:

> Hi Vlad,
>
> Thanks for the quick reply.
>
> The length of the token is defined as its length in characters. That is all
> fine for most tokens that are on a single line, but things go to hell when
> you take into account multiline strings, atoms and chars.
>
> --
> Anthony Ramine
>
> Le 20 mars 2013 à 13:49, Vlad Dumitrescu a écrit :
>
> > Hi Anthony,
> >
> > Don't the tokens have a start position and a length? Why do you need an
> explicit end position?
> >
> > regards,
> > Vlad
> >
> >
> >
> > On Wed, Mar 20, 2013 at 1:44 PM, Anthony Ramine <>
> wrote:
> > Hi,
> >
> > Replying on list because I think it's important.
> >
> > As I said to someone I don't remember the name, this patch is only a
> > necessary step to what my final goal is: Clang-like diagnostics for
> > Erlang compilation [1]. Is that something the OTP team wouldn't like
> > to see?
> >
> > How is the end location in tokens redundant? I need the end locations
> > of each tokens to be able to compute the location ranges of each node
> > in the AST, see my work-in-progress commit for more informations [2].
> >
> > That being said, I am interested in having your feedback about the
> > implementation.
> >
> > Regards,
> >
> > [1] http://clang.llvm.org/diagnostics.html
> > [2] https://github.com/nox/otp/commit/2c8038c#diff-1
> >
> > PS: Sorry Hans for replying twice, I failed the Cc header.
> >
> > --
> > Anthony Ramine
> >
> > Le 20 mars 2013 à 13:23, Hans Bolinder a écrit :
> >
> > > Hi Anthony,
> > >
> > > Sorry for not replying sooner.
> > >
> > > We'll most likely reject you patch. I asked Vlad Dumitrescu about it,
> > > and he agrees with me that the functionality (the end location of
> > > tokens) is redundant.
> > >
> > > Apart from that: when it comes to the implementation there are a few
> > > things I don't approve of, but I need to take a closer look before
> > > saying anything more. You've put in a good effort here, and I intend
> > > to elaborate a little more on the implementation when I find the time
> > > to investigate in more detail.
> > >
> > > Best regards,
> > >
> > > Hans Bolinder, Erlang/OTP team, Ericsson
> >
> > _______________________________________________
> > erlang-patches mailing list
> > 
> > http://erlang.org/mailman/listinfo/erlang-patches
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-patches/attachments/20130320/ffb19c9d/attachment.html>


More information about the erlang-patches mailing list