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

Implement Static Typing #48

Closed
dgp1130 opened this issue Oct 20, 2016 · 3 comments
Closed

Implement Static Typing #48

dgp1130 opened this issue Oct 20, 2016 · 3 comments
Assignees
Milestone

Comments

@dgp1130
Copy link
Member

dgp1130 commented Oct 20, 2016

Due to the issues encountered in #36, we will need to introduce explicit static typing. Every identifier would need to be declared with a particular type. Using an identifier without an associated declaration should result in an UndeclaredError. This would look like the following:

boolean: hasCar; // Declare hasCar as a boolean
string: make; // Declare make as a string
number: year; // Declare year as a number
date: dueDate; // Declare dueDate as a date

In terms of types, we should probably have:
boolean
string
number
integer (should this be distinct from number?)
date (eventually, but this doesn't exist yet anyways)

We will also probably want to eventually support array types (probably not right now):

string[ ]: makes;
string[ ]: models;
number[ ]: years;

We have two options for scope, either 1) require that they be declared in the root scope, or 2) allow scoping the same way we do with variables. The first would effectively make all identifiers global (eww, but sort of the way it actually works behind the scenes). The second would compartmentalize better, but is a little strange in that the user may have to declare the same variable twice in two different scopes, which can be a somewhat counter-intuitive.

@myForm {
    string: make;
    valid: make equals "test"; // Works
}

@myOtherForm {
    valid: make equals "test"; // UndeclaredError
}

@myOtherOtherForm {
    string: make; // So this is the same as @myForm's make?
    valid: make equals "test";
}

I think I'm leaning towards making identifiers inherently global as I think the extra confusion and complexity of allowing scope would outweigh the small compartmentalization benefit it provides. Thoughts @sawyernovak?

@dgp1130 dgp1130 added this to the Language Reimplementation milestone Oct 20, 2016
@dgp1130 dgp1130 self-assigned this Nov 6, 2016
dgp1130 added a commit that referenced this issue Nov 6, 2016
dgp1130 added a commit that referenced this issue Nov 6, 2016
Updating parser.js comment grammar.
@dgp1130 dgp1130 assigned sawyernovak and unassigned dgp1130 Nov 6, 2016
@dgp1130
Copy link
Member Author

dgp1130 commented Nov 6, 2016

Added static typing. Uniform now requires a declaration before an identifier can be used. Declarations must be put in the root scope and use the grammar <type> : <identifier> ; The full grammar on the wiki has been updated to reflect this. This addresses the issue of using submitting the text on into one of the text fields on car form. I didn't bother with checking types at compile type as that will be handled by #49.

I removed the is operator as part of this. It was intended to check types dynamically, ie. @isString: make is string. Since types are statically defined in the Uniform file, this no longer makes sense, since make was either defined as a string or it wasn't. Hopefully the programmer is competent enough to figure that out, since they're the one that declared it.

Also made some minor edits involving adding $(document).ready(function () { ... }). I came across a few instances where Uniform was loading before the DOM and was unable to correctly initialize, so I added this to address that.

@sawyernovak
Copy link
Collaborator

I like the new change. After working through the car form tutorial, I was able to pick it up fairly quickly. Is vs equals was already confusing so I'm glad the distinction is gone. You also mentioned adding integer, array, and date in this ticket. Do you want to add a separate ticket for those? Code review is done, but you can close this if new types are a separate ticket.

@dgp1130
Copy link
Member Author

dgp1130 commented Dec 24, 2016

Dates / times are handled in #16.
Created #63 for arrays.
Created #64 for numeric types.
Also created #65 and #66 for select boxes and radio buttons which are pretty significant input types.

@dgp1130 dgp1130 closed this as completed Dec 24, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants