Skip to content

Refactor: construct every Ptyp_arrow via Ast_helper.Typ.arrow. #7647

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

Merged
merged 2 commits into from
Jul 17, 2025

Conversation

cristianoc
Copy link
Collaborator

@cristianoc cristianoc commented Jul 15, 2025

This should give an explicit handle over how all arrow types are constructed (for the untyped parse tree).

This should give an explicit handle over how all arrow types are constructed.
Copy link

pkg-pr-new bot commented Jul 15, 2025

Open in StackBlitz

rescript

npm i https://pkg.pr.new/rescript-lang/rescript@7647

@rescript/darwin-arm64

npm i https://pkg.pr.new/rescript-lang/rescript/@rescript/darwin-arm64@7647

@rescript/darwin-x64

npm i https://pkg.pr.new/rescript-lang/rescript/@rescript/darwin-x64@7647

@rescript/linux-arm64

npm i https://pkg.pr.new/rescript-lang/rescript/@rescript/linux-arm64@7647

@rescript/linux-x64

npm i https://pkg.pr.new/rescript-lang/rescript/@rescript/linux-x64@7647

@rescript/win32-x64

npm i https://pkg.pr.new/rescript-lang/rescript/@rescript/win32-x64@7647

commit: 6130881

… arguments.

The arity is inferred, by just the length of the list of arguments.
@@ -56,6 +56,7 @@ module Typ : sig
val var : ?loc:loc -> ?attrs:attrs -> string -> core_type
val arrow :
?loc:loc -> ?attrs:attrs -> arity:arity -> arg -> core_type -> core_type
val arrows : ?loc:loc -> ?attrs:attrs -> arg list -> core_type -> core_type
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This begins to run into trouble when one would like to use it for examples such as this one:

@obj
external renamed_make: (
  @as("type") ~_type: string,
  @as("WIDTH") ~width: int=?,
  ~normal: float,
) => (_ as 'event) = ""

Currently the @as attributes are stored in each ast node, and they are not really part of arg, so we can't use the current arrows function.

I think we'll need to first change the AST so attributes can be stored in arguments, then store them there instead of in the AST nodes themselves.

I think it makes sense to support type @attr (@attr1 ~x1: t1, @attr2 ~x2:t2) => t, where @attr goes in the attributes of top-level node, and the rest go in the args. Then change the rest of the compiler to pick up attributes from the argument.

@zth I guess this rings a bell with other issue found in the past?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Definitely! I agree.

@cristianoc cristianoc requested a review from zth July 16, 2025 18:05
@cristianoc cristianoc merged commit 2c96b79 into master Jul 17, 2025
13 of 14 checks passed
@cristianoc cristianoc deleted the arrow-type-construction branch July 17, 2025 06:29
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 this pull request may close these issues.

2 participants