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: add possibility to omit .type. #2631

Conversation

michaellilltokiwa
Copy link
Member

Copy link
Member

@fridis fridis left a comment

Choose a reason for hiding this comment

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

Looks great!

Will have a detailed look into it tomorrow.

…ype features.

also added comments and a test showcasing an issue of ambiguity
@michaellilltokiwa michaellilltokiwa marked this pull request as ready for review February 29, 2024 09:32
@michaellilltokiwa michaellilltokiwa marked this pull request as draft February 29, 2024 09:33
Copy link
Member

@fridis fridis left a comment

Choose a reason for hiding this comment

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

I am very happy with this PR! Espacially, I think I could use some of this to later permit feature declarations to serve as type aliases, which also requires converting calls into types.

* @param feat the outer feature this type is declared in. Lookup of
* unqualified types will happen in this feature.
*/
AbstractType tryResolve(Resolution res, AbstractFeature outerfeat)
Copy link
Member

Choose a reason for hiding this comment

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

Would be nice to avoid code duplication by adding a method

  resolve(Resolution res, AbstractFeature outerfeat, boolean justTry)

and call this both by resolve and tryResolve.

src/dev/flang/ast/UnresolvedType.java Outdated Show resolved Hide resolved
tests/calls_on_ref_and_val_target/calls.fz Outdated Show resolved Hide resolved
tests/dot_type_call_ambiguity/dot_type_call_ambiguity.fz Outdated Show resolved Hide resolved

type.a => 4

# NYI should result in an error: Duplicate feature declaration or similar.
Copy link
Member

@fridis fridis Feb 29, 2024

Choose a reason for hiding this comment

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

We can solve this later, but here are my thoughts:

A duplicate feature is a bit difficult to define when you take visibility into account.

I prefer to cause an error at an ambiguous call and to provide a means to disambiguate the calls:

ex is 
  a => 3
  type.a => 4

say ex.a    # should cause an error, ambiguous!

To make a call on the type feature, one could write

say ex.type.a

It is a bit harder to make a call on the instance, one ugly solution might be a temp field:

  temp := ex
  temp.a

Nicer might be to add an instance (or self, me, thiz) to Any.fz

public Any ref is
  ...
  public instance => Any.this

then we might be able to do

say ex.instance.a

@michaellilltokiwa michaellilltokiwa marked this pull request as ready for review March 1, 2024 08:25
@michaellilltokiwa michaellilltokiwa linked an issue Mar 1, 2024 that may be closed by this pull request
@michaellilltokiwa michaellilltokiwa added Fuzion language related to the language, syntax, etc front end related to the front end until .fum file is created: call and type resolution, type checking, etc. enhancement New feature or request labels Mar 1, 2024
Copy link
Member

@fridis fridis left a comment

Choose a reason for hiding this comment

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

please create 2 issues for my unresolved comments.

@fridis fridis merged commit 5091f9b into tokiwa-software:main Mar 4, 2024
4 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request front end related to the front end until .fum file is created: call and type resolution, type checking, etc. Fuzion language related to the language, syntax, etc
Projects
None yet
Development

Successfully merging this pull request may close these issues.

What if we dropped the need for .type in calls?
2 participants