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

Thoughts on TASTy grammar #27

Open
cache-nez opened this issue Sep 14, 2021 · 4 comments
Open

Thoughts on TASTy grammar #27

cache-nez opened this issue Sep 14, 2021 · 4 comments
Labels
discussion Open ended discussion, not immediately actionable

Comments

@cache-nez
Copy link
Contributor

This is the list of my impressions from working with the TASTy grammar, which can hopefully be useful for an eventual discussion of TASTy. Additions are welcome.

  • It is hard to recover the type of a parent because of the surrounding Apply / Block, representing the call to the constructor
  • package is sometimes referenced in a special way: as THIS TYPEREFpkg <empty> rather than TERMREFpkg <empty>
  • if a MATCHtpt has a BIND(_) inside, the bound ident is represented as IDENT (rather than IDENTtpt) even though it represents a type
  • at the phase when TASTy is produced, we probably already know which of the parents SUPER refers to. However, this is not included in .tasty file. Perhaps this can be included to avoid re-resolution.
@bishabosha bishabosha added the discussion Open ended discussion, not immediately actionable label Mar 16, 2022
@sjrd
Copy link
Contributor

sjrd commented Sep 8, 2022

New thing: DefDefs don't have a SignedName at definition site. It needs to be recomputed from the erasure, which requires dereferencing all the types in the signautre.

@sjrd
Copy link
Contributor

sjrd commented Dec 8, 2022

TermRefs for private (and even local like non-val constructor param) members should always be TERMREFsymbols, so that name-based field selection can systematically filter out Private and be done with it. private members are never accessible from another .tasty file, so we always have access to the symbol.

@sjrd
Copy link
Contributor

sjrd commented Feb 10, 2023

SuperTypes should not exist at all. They may have had a reason to exist when it was possible to shadow an inherited class with another class, but that is not allowed in Scala 3 anymore.

Super nodes should not exist as a dedicated thing. They should be fused with their enclosing Select as SuperSelect, and be reserved to term selection.

@sjrd
Copy link
Contributor

sjrd commented Dec 20, 2023

scala/scala3#19307

The param of AnyVal classes should never have the LOCAL flag, because it gets automatically accessed on another instance in the generated equals method. Example:

class ValueClassNonVal(self: String) extends AnyVal:
  def get: String = self // TERMREFsymbol, OK
  def getThroughThis: String = this.self // SELECT, ~OK because this prefix

  // def getOther(that: ValueClassNonVal): String = that.self // does not compile, rightly so

  // <generated>
  def equals(x$0: Any): Boolean = x$0 match
    case x$0: ValueClassNonVal =>
      this.self // SELECT, ~OK because this prefix
        == x$0.self // SELECT, definitely not OK
    case _ =>
      false
end ValueClassNonVal

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion Open ended discussion, not immediately actionable
Projects
None yet
Development

No branches or pull requests

3 participants