sikanhe ( Sikan He )

commit sha 0bc0fd037971b1adb991476af81002cb5f2aa6d1

Tweak `variantIdent` error message based on feedback from bloodyowl Co-authored-by: Matthias Le Brun <[email protected]>

Don't parse Int token with suffices as hash ident for poly variants

push time in 2 days

Pull request review commentrescript-lang/syntax

 Explanation: since records have a known, fixed shape, a spread like `{a, ...b}` Explanation: lists are singly-linked list, where a node contains a value and points to the next node. `list[a, ...bc]` efficiently creates a new item and links `bc` as its next nodes. `[...bc, a]` would be expensive, as it'd need to traverse `bc` and prepend each item to `a` one by one. We therefore disallow such syntax sugar.\n\ Solution: directly use `concat`." -  let variantIdent = "A polymorphic variant (e.g. #id) must start with an alphabetical letter."+  let variantIdent = "A polymorphic variant (e.g. #id) must start with an alphabetical letter or is a number (e.g. #742)"

Thanks, this sentence definitely needed work.

IwanKaramazow

comment created time in 2 days

pull request commentrescript-lang/syntax

Don't parse Int token with suffices as hash ident for poly variants

Yes, thanks for the suggestion, will do!

IwanKaramazow

comment created time in 2 days

pull request commentrescript-lang/syntax

Don't parse Int token with suffices as hash ident for poly variants

maybe a good time to turn on warning 9 to avoid it in the future?

IwanKaramazow

comment created time in 2 days

Pull request review commentrescript-lang/syntax

Don't parse Int token with suffices as hash ident for poly variants

 Explanation: since records have a known, fixed shape, a spread like `{a, ...b}` Explanation: lists are singly-linked list, where a node contains a value and points to the next node. `list[a, ...bc]` efficiently creates a new item and links `bc` as its next nodes. `[...bc, a]` would be expensive, as it'd need to traverse `bc` and prepend each item to `a` one by one. We therefore disallow such syntax sugar.\n\ Solution: directly use `concat`." -  let variantIdent = "A polymorphic variant (e.g. #id) must start with an alphabetical letter."+  let variantIdent = "A polymorphic variant (e.g. #id) must start with an alphabetical letter or is a number (e.g. #742)"

  let variantIdent = "A polymorphic variant (e.g. #id) must start with an alphabetical letter or be a number (e.g. #742)"

IwanKaramazow

comment created time in 3 days

PR opened rescript-lang/syntax

Don't parse Int token with suffices as hash ident for poly variants

#10s should not be accepted as a numeric polyvariant identifier.

Fixes https://github.com/rescript-lang/syntax/issues/407

+47 -3

1 commit in rescript-lang/syntax/tree/GH407 rescript-lang/syntax/tree/master

0 comment

3 changed files

pr created time in 3 days

create barnchrescript-lang/syntax

branch : GH407

created branch time in 3 days

issue commentrescript-lang/syntax

nulary polymrophic variants starting with leading number are compiled to numbers

Yes, confirmed the bug on my side, should be matching on | Int {i; suffix = None} ->. Int like tokens with a suffix don't qualify as numeric polyvars.

Will make a PR.

amiralies

comment created time in 4 days

issue openedrescript-lang/syntax

nulary polymrophic variants starting with leading number are compiled to numbers

for example

let a = #10s

is compiled to

va a = 10

as result if this if I have a type containing #10s and #10m, these two values are eqivalent

created time in 4 days

issue commentrescript-lang/syntax

Express list literal variants

Something like:

type rec t<'a> =
| Empty
| Cons('a, t<'a>)

rickyvetter

comment created time in 5 days

startedsikanhe/gqtx

started time in 5 days

issue openedrescript-lang/syntax

Remove `{path as p}` record pattern

This formats to {path: p}, which is the right syntax. The as syntax is unnecessarily confusing sugar.

created time in 5 days

pull request commentsikanhe/gqtx

refactor!: merge `defaultField` and `field`

I created https://github.com/FedericoBiccheddu/gqtx/pull/1 for unifying the API with the t.type API as well as handling optional resolve

FedericoBiccheddu

comment created time in 6 days

push eventrescript-lang/syntax

commit sha e8479c72e72d84b0262ff7007e883f7bf2e1adfd

Fix printing of Osig_module in outcome printer. (#404) Modules types don't use a `=`, it should be a `:`. ``` module Expr: { … } ```

Cheng Lou

commit sha b89849d8ec7bb66e93d2e3400d53f784b1bb010a

Tiny cleanup

commit sha acaedb35b9e131a454a70052bca628b216b019d4

Work

commit sha 5257a1cf5d71efc3b6faf42742ac2da1c7d1b4c4

add tests

commit sha 72d9a104432b9339da33b90238571f267b8f1e2a

Preserve original char encoding in printer

push time in 6 days

issue commentrescript-lang/syntax

Aside from the technical challenges in a reverse conversion, the above snippet is a bug in refmt. Refmt will print:

let make = (~columns as [@attr] columns, ~rows as [@attr] rows) => ()

as

let make = (~[@attr] columns, ~[@attr] rows) => ()

Refmt doesn't support this syntax, so it's an idempotency problem inside its parser/printer. It's advised to stick to ReScript syntax, both for support and learning purposes. We designed the new syntax to be easier to read and it also features a more responsive typing experience.

jchavarri

comment created time in 6 days

issue closedrescript-lang/syntax

Hi there 👋 Thanks a lot for your work on the ReScript parser :)

We have been testing conversion from res to re syntax, and the generated code seems to be invalid. Here's an example in playground.

The produced code contains attributes in unexpected places:

  let make =
      (
        ~[@ns.namedArgLoc] columns,
        ^^^
  [E] Line 12, column 9:

  We've found a bug for you!
  playground.re:12:10-11
  
  Syntax error

Would there be a way of removing the [@ns.namedArgLoc] from the Reason output? Or are there more attributes / syntax additions in ReScript that would make this conversion hard to implement and support? Even if just for learning purposes in the playground while transitioning to new syntax, maybe there is a use case to support res -> re translations?

closed time in 6 days

jchavarri

issue commentrescript-lang/syntax

Technically, it is impossible to convert the whole res syntax into re and vice versa. (Think about poly var and the forthcoming unicode). It is generally discouraged to write new projects with reason syntax so I am not sure the point in converting res syntax to re, we will eventually remove the reason syntax (that would be a long time though).

jchavarri

comment created time in 6 days

issue openedrescript-lang/syntax

Hi there 👋 Thanks a lot for your work on the ReScript parser :)

We have been testing conversion from res to re syntax, and the generated code seems to be invalid. Here's an example in playground.

The produced code contains attributes in unexpected places:

  let make =
      (
        ~[@ns.namedArgLoc] columns,
        ^^^
  [E] Line 12, column 9:

  We've found a bug for you!
  playground.re:12:10-11
  
  Syntax error

Would there be a way of removing the [@ns.namedArgLoc] from the Reason output? Or are there more attributes / syntax additions in ReScript that would make this conversion hard to implement and support? Even if just for learning purposes in the playground while transitioning to new syntax, maybe there is a use case to support res -> re translations?

created time in 7 days

push eventrescript-lang/syntax

Cheng Lou

commit sha b89849d8ec7bb66e93d2e3400d53f784b1bb010a

Tiny cleanup