Elm: minor issues

[masatake]

This issue gathers minor topics about the Elm parser.
These topics are not the reason to delay merging #3312, Peg based ELM parser.

• normalize typeref values

port outgoing : Enc.Value                                            -> Cmd msg

Though many spaces are between Value and ->, the tags output should be:

outgoing	...	typeref:description:Enc.Value -> Cmd msg	roles:def

or

outgoing	...	typeref:description:Enc.Value->Cmd msg	roles:def

The request for normalization is popular. So vString should provides a utility function that can be used in many parsers.

• normalize signature fields
• tagging function parameters
• exported (or exposed) role for tagging f in import A exposing (f) module A exposing (f) as a reference tag
• attach file: field if f is exposed from a module (I misunderstood the meaning of file:.)

---

Quoted from elm.peg:

# To do:
# Maybe do:
# - let/in blocks
#   - Allow tuples on the LHS. Eg '(val1, val2) = valFunc'.
#   - Inner functions' type annotations are used in the function's
#     type description.
#   - Inner functions can have more complex parameters.
# - Functions
#   - Allow non-Latin upper and lower case. Use
#     https://util.unicode.org/UnicodeJsps/properties.html
#     combined with \p{Lu}, \p{Ll} and \p{L}.

---

• https://elm-lang.org/docs/syntax
• https://elm-lang.org/examples/hello

[niksilver]

tagging function parameters

This could be useful if it could be used by an IDE.

I would think each parameter would be in the scope of its function. If the function had a type annotation the parser might be able to determine the parameter's type.

However, parameters may not just be simple identifiers. Elm's pattern matching allows quite complex parameter patterns. See the unit tests in elm-parameter-patterns.d:

funcA (a1, _, a2) = ...
funcB (b1, b2) (b3, b4) = ...
funcC {c1} {c2, c3} = ...
funcD (D1Cons a b) (D2Cons a b, D3Cons a b) = ...
funcE (D1Cons {a, b} c) d = ...
funcF (D1Cons ({a, b} as ab) c) (d as d2) = ...

funcE takes two parameters, and as defined above the first one is (D1Cons {a, b} c). I don't think if that is a useful "tag". The more useful tags are a, b and c - those are the values that someone will use in the function body. They are created thanks to Elm's pattern matching. If those are the tags, they are more difficult to extract. It will be even more difficult to determine their types.

But it would be a good thing to do.

exported (or exposed) role for tagging f in import A exposing (f) as a reference tag

This is discussed in PR #3312. I will do that as a bug fix if you confirm.

attach file: field if f is exposed from a module

I am not sure what the proposal is here.

If the situation is

module A.B.C exposing (f)

f = ...

then ctags already records that f is in file A/B/C.elm.

If the situation is

import A.B.C exposing (f)

then we can expect that f will be in file A/B/C.elm relative to the top of the source tree. The file: field could be calculated (convert . to / (operating system dependent) and add .elm at the end). However, that would only point to the file, not the location of f within the file.

[masatake]

Thank you for your comment.

I'm sorry that I took many mistakes when writing the TODO items.

• I found using file: was not suitable. I misunderstood the meaning of file:.
• I wrote about f in import A exposing (f). What I should write was f in module A exposing (f).
  I fixed the items with strikethroughs.

I will write my concern:

C.elm

1: module A.B.C exposing (f)
2: f = 'a'

I'm thinking about f in line 1.

f ... kind:function line:1 roles:exposed  scope:Module:A.B.C extras:reference

This one itself is not bad. However, the tag entry is too similar to

f ... kind:function line:1 roles:exposed  scope:Module:A.B.D extras:reference

extracted from D.elm

import A.B.D exposing (f)

If we use different roles for each context, we can distinguish the two easily:

f ... kind:function line:1 roles:exported  scope:Module:A.B.C extras:reference
f ... kind:function line:1 roles:imported  scope:Module:A.B.D extras:reference

The current implementation doesn't extract f in C.elm. So there is no issue here.
As you commented, the definition of f can be solved.
However, I wonder how an ideal parser deals with f in module A.B.C exposing(f).

[masatake]

In the python parser, I took a long time to design the way to handle import.
https://docs.ctags.io/en/latest/man/ctags-lang-python.7.html

[masatake]

f ... kind:function line:1 roles:exported  scope:Module:A.B.C extras:reference
f ... kind:function line:1 roles:imported  scope:Module:A.B.D extras:reference

Though the two are too similar, the context where f appears can be known easily from the scope field.
For the first f, if a client tool looks up A.B.C in the same file where the f is tagged, the tool may
know is A.B.C is a definition.

For the second f, if a client tool looks up A.B.D in the same file where the f is tagged, the tool may
know is A.B.D is a reference tag having imported role. So the similarity of the two tags for f is acceptable.

What I would like to do is making a reference tag for f in module A.B.C exposing (f) as ctags already extracts
f in import A.B.D exposing (f). It seems that reusing the exposed role is o.k.
I'll explain the benefit of extracting f in module A.B.C exposing (f).

module A.B.C exposing (f)

f = ...
g = ...

Though f is exposed, and g is not, the definition tags for f (at line 3) and g cannot show the difference.
Tagging f at line 1 as a reference tag can show the difference.