Misuse of terminology in `parser-tools/lex`?

[Matthew Butterick]

Forgive the possibly noobish question. 

Racket's name for a precise place in a source file is called a source location [1] — sometimes abbreviated `srcloc` — and has four possible fields: line, column, position, and span.

The `parser-tools/lex` library also dabbles in source locations, but IIUC calls them "positions" rather than "locations" [2]. Moreover, what is known as the "position" field in a Racket source location is called an "offset" in `parser-tools/lex`. [also 2]

So is it fair to say that `parser-tools/lex` is using names that are inconsistent with Racket (and, in the case of "position", contradictory)?

[1] http://docs.racket-lang.org/reference/exns.html?q=srcloc#%28def._%28%28lib._racket%2Fprivate%2Fbase..rkt%29._srcloc%29%29

[2] http://docs.racket-lang.org/parser-tools/Lexers.html#%28def._%28%28lib._parser-tools%2Flex..rkt%29._position%29%29

[Jens Axel Søgaard]

The names are consistent with the position tracking for ports:

http://docs.racket-lang.org/reference/linecol.html?q=Syntax%20objects

--
You received this message because you are subscribed to the Google Groups "Racket Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to racket-dev+...@googlegroups.com.
To post to this group, send email to racke...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/racket-dev/B26F0406-4DA6-42F9-83DE-9C2D4BE9C90A%40mbtype.com.
For more options, visit https://groups.google.com/d/optout.

[Matthew Butterick]

On Thursday, December 8, 2016 at 11:52:08 AM UTC-8, Jens Axel Søgaard wrote:

The names are consistent with the position tracking for ports:

http://docs.racket-lang.org/reference/linecol.html?q=Syntax%20objects

 

Now I'm more confused. This part of the docs talks about a "location" as consisting of three values: line, column, and position. See, e.g. `port-next-location`. [1]

This, to me, seems consistent with the existing Racket lingo of source locations [2], where line, column, and position are fields within a location.

[1] http://docs.racket-lang.org/reference/linecol.html?q=Syntax%20objects#%28def._%28%28quote._~23~25kernel%29._port-next-location%29%29

[2] http://docs.racket-lang.org/reference/exns.html?q=srcloc#%28def._%28%28lib._racket%2Fprivate%2Fbase..rkt%29._srcloc%29%29

[Robby Findler]

It may be that at the time the parser-tools were developed, we were
not yet using a struct for srclocs. I think today we would not do what
the parser tools are doing.

Robby

[Matthew Butterick]

1) Would you consider a PR (from me) for `parser-tools` that updates the names to be consistent (while preserving the older ones of course)? Or is there too much water under the bridge to bother with?

2) Relatedly: is the field ordering used by the `srcloc` struct — line / column / position / span — recommended for other interfaces to follow, or considered arbitrary?

[Robby Findler]

On Fri, Dec 9, 2016 at 12:23 PM, Matthew Butterick <m...@mbtype.com> wrote:
> 1) Would you consider a PR (from me) for `parser-tools` that updates the
> names to be consistent (while preserving the older ones of course)? Or is
> there too much water under the bridge to bother with?

Sure, cleaning up stuff like that sounds quite welcome. And the parser
tools could use a lot of clean up, I believe. They are kind of strange
and klunky compared to modern racket.

> 2) Relatedly: is the field ordering used by the `srcloc` struct — line /
> column / position / span — recommended for other interfaces to follow, or
> considered arbitrary?

I would probably say "both".

Robby

[Alexis King]

> On Dec 9, 2016, at 10:23, Matthew Butterick <m...@mbtype.com> wrote:
>
> 2) Relatedly: is the field ordering used by the `srcloc` struct — line
> / column / position / span — recommended for other interfaces to
> follow, or considered arbitrary?

IMO, I would say “just use the srcloc struct” if you need srclocs, don’t
mess around with functions that accept 5 additional arguments. That’s
what I did in megaparsack, and it produces a much cleaner interface,
especially since they’re much easier to functionally update if you want
that sort of thing.

[Matthew Butterick]

On Friday, December 9, 2016 at 10:25:06 AM UTC-8, robby wrote:

Sure, cleaning up stuff like that sounds quite welcome. And the parser 
tools could use a lot of clean up, I believe. They are kind of strange 
and klunky compared to modern racket. 

What expectation of backward compatibility is baked into `parser-tools`? How much modernization is acceptable?

IOW, suppose I've added a `lexer-srcloc` variant of `lexer-src-pos` that uses srcloc structs rather than the "strange and klunky" structures currently used by `parser-tools`. But that creates a dependency on the `srcloc` structure in modern Racket, which might annoy the MzScheme v372 community.