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

General improvements to the ECMA-SL syntax #133

Merged
merged 6 commits into from
Jun 27, 2024
Merged

Conversation

andreffnascimento
Copy link
Contributor

@andreffnascimento andreffnascimento commented Jun 26, 2024

In this PR, we give a general overall to the ECMA-SL syntax (this is useful before starting #130). Additionally, we fix a couple of problems introduced in #128. The list of changes is the following:

  • T1: In this commit, we merged all the metadata files (e.g., eFunc_metadata, EPat_metadata, etc.) into a single file. Additionally, we removed a few unused functions and improved overall consistency.

  • T2: In this commit, we separated the Syntax.Source and Syntax.Source.Code modules in two different files. Since the latter is only used to store the parsed code, it is not needed in the language syntax, and thus was moved to the Code_utils.ml file.

  • T3: In this commit, we encapsulated Smtml.Value in our own Value module, similar to what we did with the Format module. This allows us to store value-related functions within this module instead of storing them in the EExpr module. Additionally, we no longer require opening the Smtml module (generally) as the value can now be directly accessed through the ESLSyntax library. Finally, we removed type values, since dynamic types are now represented by normal string values.

  • T4: In this commit, we replaced the Type module with the types from Smtml. Dynamic types are not needed any longer, and this allows symbolic expressions to immediately store Smtml types rather than having to convert the old dynamic types into these.

This commit removes dynamic types from the lexer/parser, as they are now
represented by normal strings in the typeof operator. Therefore, there is
no need to store a type as a value. This change should not break any existing
functionality.
@andreffnascimento andreffnascimento self-assigned this Jun 26, 2024
@andreffnascimento andreffnascimento changed the title General improvements to the ECMA-SL syntax and parser General improvements to the ECMA-SL syntax Jun 26, 2024
@andreffnascimento andreffnascimento added no changelog Skip changelog CI check scope-language Related to the ECMA-SL language design refactor General change of the implementation and removed draft labels Jun 27, 2024
| App (`Op "TupleType", [])
| App (`Op "CurryType", []) ->
Str "type"
| App (`Op "type", [ Str _ ]) -> Str "type"
Copy link
Member

@filipeom filipeom Jun 27, 2024

Choose a reason for hiding this comment

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

Suggested change
| App (`Op "type", [ Str _ ]) -> Str "type"
| App (`Op "type", [ Str _ ]) -> Str "type"

I don't understand why we still need this? This PR removes parsing of Types, so we should never create this value right?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Absolutely, I went over this file before I removed the types

@andreffnascimento andreffnascimento merged commit cec0f2e into main Jun 27, 2024
2 checks passed
@andreffnascimento andreffnascimento deleted the polish-parser branch June 27, 2024 15:25
filipeom pushed a commit that referenced this pull request Dec 27, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
no changelog Skip changelog CI check refactor General change of the implementation scope-language Related to the ECMA-SL language design
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants