Skip to content

Conversation

AStenbaek
Copy link

@AStenbaek AStenbaek commented Aug 7, 2025

Resolves #52

Tasks

  • Add rudementary encoding of ADTs as records tuples.
  • Add more tests.
  • Improve on errors.
  • Rudementary type checking; this also provides scaffolding for gradual type checking.

@aslanix
Copy link
Contributor

aslanix commented Aug 7, 2025

any insight on the failing test?

@ssoelvsten ssoelvsten added 📁 ./compiler Changes, errors, and additions for the compiler ✨ enhancement New feature or request labels Sep 14, 2025
@aslanix
Copy link
Contributor

aslanix commented Sep 19, 2025

This needs better description of the extent to which this accomplishes #52 (what has been done, what are the currently known limitations, etc).

@aslanix aslanix marked this pull request as draft September 19, 2025 13:02
@aslanix
Copy link
Contributor

aslanix commented Sep 20, 2025

I've taken a look, and I'm now wondering why we shouldn't go directly to tuples instead of records?

@AStenbaek
Copy link
Author

I've taken a look, and I'm now wondering why we shouldn't go directly to tuples instead of records?

I already started this refactoring last weekend. :)
I actually thought we already agreed on this, since we wanted to move away from relying on JS record.

@aslanix
Copy link
Contributor

aslanix commented Sep 20, 2025

ok, then let's wait and update the PR once that refactoring is complete.

@AStenbaek
Copy link
Author

ok, then let's wait and update the PR once that refactoring is complete.

Implementation has been refactored to use Tuples

type VarName = String
type AtomName = String
type DataTypeName = String
type TypeConstructorName = String
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggestion for naming: TypeConstructorName -> VariantConstructorName

type AtomName = String
type DataTypeName = String
type TypeConstructorName = String
type TypeConstructor = (TypeConstructorName, [VarName])
Copy link
Contributor

Choose a reason for hiding this comment

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

Similar to the above. TypeConstructor -> VariantConstructor, or even better SyntacticVariantConstructor to reflect what is going on in here.

| LUnit
| LBool Bool
| LAtom AtomName
| LAtom TypeConstructorName
Copy link
Contributor

Choose a reason for hiding this comment

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

If Atoms are to be phased out, then shouldn’t we rename them in the codebase as well?

, RecordPatternMode(..)
, AtomName
, Atoms(..)
, DataTypeName
Copy link
Contributor

Choose a reason for hiding this comment

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

let's follow the convention of "syntactic variants"

@aslanix
Copy link
Contributor

aslanix commented Sep 22, 2025

I've looked through a few files in the codebase. One general comment is that we should avoid using the word "type" if we can; and in this case, one suggested name is "syntactic variants". If that's okay, let's just use that naming consistently throughout the codebase. Some examples are in the code-specific comments inline. Another one "ADTag" -> "SynVariantTag"

@AStenbaek AStenbaek changed the title Atoms are now converted to tagged records in AtomFolding.hs Syntactic Variants Sep 28, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

📁 ./compiler Changes, errors, and additions for the compiler ✨ enhancement New feature or request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants