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

fe, tests: Type inference for formal arguments #1722

Merged
merged 3 commits into from
Jul 13, 2023

Conversation

fridis
Copy link
Member

@fridis fridis commented Jul 13, 2023

NOTE: This is experimental, would like to gain experience and know if this is useful or does harm.

With this patch, formal arguments types in a feature declaration can be omitted provided that the currently compiled module has a call to the formal argument's outer feature that provides an actual argument that permits type inference.

As an example, here is the first example from https://flang.dev/tutorial/feature_decl_fields

    Point(x, y i32) is

    show (Point 3 4 )
    show (Point 5 12)

    show(p Point) => say "{p.x}, {p.y}"

Type inference permits omitting all formal argument types in this example, so we can omit i32 and Point types for x, y and p and write

    Point(x, y) is

    show (Point 3 4 )
    show (Point 5 12)

    show(p) => say "{p.x}, {p.y}"

This looks like magic, but it is in fact just a removal of redundant information, the language is still fully statically typed. One caveat is that the documentation function of types in the source code gets lost, in particular since the call to a feature may be far away from its declaration, even in a separate file, but always in the same module. Documentation tools like fz -docs operate after the front end is done, so they should have full type information.

This, however, also creates new possibilities for errors: First, there might be several calls to the same feature with incompatible actual argument types. Second, there might be no call at all so the argument type is unknown. Both cases result in new errors.

A new negative test typeinference_for_formal_args_negative checks these error cases.

With this patch, formal arguments types in a feature declaration can be omitted
provided that the currently compiled module has a call to the formal argument's
outer feature that provides an actual argument that permits type inference.

As an example, here is the first example from https://flang.dev/tutorial/feature_decl_fields

    Point(x, y i32) is

    show (Point 3 4 )
    show (Point 5 12)

    show(p Point) => say "{p.x}, {p.y}"

Type inference permits omitting all formal argument types in this example, so we
can omit `i32` and `Point` types for `x`, `y` and `p` and write

    Point(x, y) is

    show (Point 3 4 )
    show (Point 5 12)

    show(p) => say "{p.x}, {p.y}"

This looks like magic, but it is in fact just a removal of redundant
information, the language is still fully statically typed.  One caveat is that
the documentation function of types in the source code gets lost, in particular
since the call to a feature may be far away from its declaration, even in a
separate file, but always in the same module. Documentation tools like `fz
-docs` operate after the front end is done, so they should have full type
information.

This, however, also creates new possibilities for errors: First, there might be
several calls to the same feature with incompatible actual argument types.
Second, there might be no call at all so the argument type is unknown. Both
cases result in new errors.

A new negative test `typeinference_for_formal_args_negative` checks these error
cases.
src/dev/flang/ast/Call.java Outdated Show resolved Hide resolved
src/dev/flang/ast/Feature.java Outdated Show resolved Hide resolved
src/dev/flang/ast/Impl.java Outdated Show resolved Hide resolved
src/dev/flang/ast/Impl.java Outdated Show resolved Hide resolved
@fridis fridis merged commit 0705871 into main Jul 13, 2023
5 checks passed
@maxteufel maxteufel deleted the type_inference_for_formal_arguments branch July 31, 2023 10:31
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.

None yet

2 participants