Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Japanese in the type constructor name, it becomes a parsing error #105

Open
ncaq opened this issue Oct 8, 2021 · 4 comments · Fixed by #112
Open

Japanese in the type constructor name, it becomes a parsing error #105

ncaq opened this issue Oct 8, 2021 · 4 comments · Fixed by #112

Comments

@ncaq
Copy link

ncaq commented Oct 8, 2021

The Elm compiler accepts the source code, but the elm-language-server recognizes it as a parsing error.

The problem is that if you put Japanese in the type constructor name, it becomes a parsing error.

The source code.

module Main exposing (..)


type Color
    = Color| Color| Color

Expected Behavior

The parsing completes normally.

Current Behavior

 Main.elm     4   1 error                           Parsing error. (lsp)

Possible Solution

The Unicode character range accepted by Elm is accepted.

Steps to Reproduce (for bugs)

  1. git init, elm init…
  2. Write a type constructor that contains Japanese.

Context

Mainly English-speaking people may think that a type constructor containing Japanese is ridiculous and that only ASCII range should be used for the constructor.

However, we are Japanese who write programs to process Japanese in Haskell.

In our team, there are almost only native Japanese speakers.
It would be unclear and inefficient for our team to go to the trouble of finding literature that explains Japanese concepts in English and use terminology expressed in inexact English to program Japanese-specific concepts.

Therefore, we used a type constructor called PredicateInflection未然 in Haskell, and converted it to Elm.
Both Haskell and Elm accepted the Japanese type constructor.

However, if LSP rejects it, the Elm source code of the corresponding part is troublesome to handle from others, though it is generated automatically.

Your Environment

  • Version used: 2.2.1
  • Editor used: Emacs
  • Environment name and version (e.g. node.js 5.4): node.js v16.10.0
  • Operating System and version: Linux 5.10.61-gentoo
@razzeee
Copy link
Member

razzeee commented Feb 3, 2022

Does this work for you with the latest release of elm-ls? It seems to be causing other regressions unfortunatly, so I'm considering to revert.
However, it seems weird, that we already shipped it and our tests did not discover the issue before.

@ncaq
Copy link
Author

ncaq commented Feb 4, 2022

I use @elm-tooling/elm-language-server 2.4.0.
I'm not sure if you can see the latest version of tree-sitter with this, but at least this version of elm-ls reproduces the problem.

@razzeee
Copy link
Member

razzeee commented Feb 4, 2022

So that version still has the problem?

@ncaq
Copy link
Author

ncaq commented Feb 4, 2022

Yes.

@razzeee razzeee reopened this Feb 4, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants