-
Notifications
You must be signed in to change notification settings - Fork 1
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
Conversation
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.
| App (`Op "TupleType", []) | ||
| App (`Op "CurryType", []) -> | ||
Str "type" | ||
| App (`Op "type", [ Str _ ]) -> Str "type" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| 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?
There was a problem hiding this comment.
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
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
andSyntax.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 theCode_utils.ml
file.T3: In this commit, we encapsulated
Smtml.Value
in our ownValue
module, similar to what we did with theFormat
module. This allows us to store value-related functions within this module instead of storing them in theEExpr
module. Additionally, we no longer require opening theSmtml
module (generally) as the value can now be directly accessed through theESLSyntax
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 fromSmtml
. Dynamic types are not needed any longer, and this allows symbolic expressions to immediately storeSmtml
types rather than having to convert the old dynamic types into these.