Add support for TypeScript type annotations #4

slotik · 2017-08-20T11:26:01Z

The changes are adaptations of TypeScript's AST nodes. The most notable differences are:

treatment of modifiers (public, protected, private, readonly, static, abstract) is somewhat stricter
parameter declarations in getters and setters are restricted as in ES2017 (the TypeScript AST in principle allows for an arbitrary parameter list)
MethodDefinition is a NamedObjectProperty but not a ClassElement as that would require multiple inheritance; composition is used instead
IndexSignatureDeclaration is treated as a special case since in TypeScript it is the only TypeElement that is also a ClassElement - perhaps this should be handled differently
some seemingly internal TypeScript interfaces are not included; an example of this is MissingDeclaration

…le and function declarations as well as call and arrow expressions. Added question token record to object properties. Stubbed out interfaces and type aliases.

…and CallExpressionE.

… mostly as documentation hints. These can be commented out or deleted later on.

slotik · 2017-08-20T11:47:11Z

src/term-spec.js

@@ -32,7 +32,7 @@ declare export class NamedObjectProperty extends ObjectProperty {
  name: PropertyName;
 }
 declare export class MethodDefinition extends NamedObjectProperty {
-  body: FunctionBody;
+  body?: FunctionBody; // undefined only on abstract class methods


This is not ideal. There are certainly other options but I'm not sure which one is best, so I went with this "minimum impact" approach for now.

I think it's better to split it out into MethodDefinition with non-optional body and AbstractMethodDefinition with no body.

I did this and while at it I found two bugs which I tried to fix. Note that I also had to add AbstractMethod, AbstractGetter and AbstractSetter which mirror the non-abstract counterparts.

slotik · 2017-08-20T11:48:47Z

src/term-spec.js

+declare export class ImplementsClause extends HeritageClause {}
+
+declare export class IndexSignatureDeclaration extends Term {
+  parent?: ClassExpression | ClassDeclaration | InterfaceDeclaration | TypeLiteralNode;


These parent? members are more for documentation than anything else. They could be turned into comments or deleted altogether.

slotik · 2017-08-20T11:50:40Z

src/term-spec.js

-  elements: ClassElement[];
+  typeParameters?: TypeParameterDeclaration[];
+  heritageClauses?: HeritageClause[];
+  elements: (ClassElement | IndexSignatureDeclaration)[];


The IndexSignatureDeclaration is handled as a special case since

It cannot be static nor have an access modifier;

It can be present on interfaces and type literals as well.

There might be a better way of dealing with it.

slotik · 2017-08-20T11:52:10Z

src/term-spec.js

+  accessModifier?: any; // 'public' | 'protected' | 'private'
+  hasReadonlyModifier: any; // boolean
+  parameter: ParameterDeclaration;
+}


I ended up with this special way of representing constructor arguments to avoid having access/readonly modifiers on all ParameterDeclarations.

@disnet Now that I'm looking at it again, it might be nicer to have ConstructorParameterDeclaration inherit from ParameterDeclaration.

slotik · 2017-08-20T11:52:57Z

src/term-spec.js

+
+// enum
+
+declare export class EnumDeclaration extends Statement {


Enum support is not strictly related to type annotations, so they could be dropped from here.

slotik · 2017-08-20T11:54:09Z

src/term-spec.js

+// example:
+//   `SomeClass[number]`
+//   where
+//   `class SomeClass { [index: number]: string }`


The comment above fails to mention that SomeClass[number] would then essentially resolve to the string type.

disnet · 2017-08-20T17:27:55Z

src/term-spec.js

+  parameter: ParameterDeclaration;
+}
+
+declare export class SemicolonClassElement extends ClassElement {}


what's the point of representing semicolons in class bodies in the AST?

This sneaked in from the TypeScript source. The comment in there says the following:

For when we encounter a semicolon in a class declaration. ES6 allows these as class elements.

So it's perhaps only used for recording and later emitting these empty semicolon statments as can be seen here.

When I added it, I probably thought it had some deep significance. Shall I remove it?

Yeah lets remove it. We of course have to parse them but as long as TypeScript doesn't give any semantic meaning to the extra semis there no reason to preserve them in the AST.

…f setter parameter. Made a separate AbstractMethodDefinition term.

slotik · 2017-08-20T20:17:26Z

src/term-spec.js

 }

 declare export class DataProperty extends NamedObjectProperty {
+  hasQuestionToken: any; // boolean


I think I may have overdone it with the question tokens. I think I added them only where the TypeScript AST permits them but some of them (like this one, but also the one on FunctionDeclaration) don't seem to make too much sense...

disnet · 2017-08-22T16:27:56Z

As discussed in sweet-js/sweet-core#742 we are going to probably need to use a reducer at the end of expansion to transform our shift-like AST into a babel AST to do codegen. Our type nodes don't need to be identical with what babel does as long as transforming ours to theirs is straightforward. That said one thing I'd definitely like to copy from babel is splitting the type nodes in Ts* and Flow* variants (https://github.com/babel/babylon/blob/master/src/types.js#L796).

slotik · 2017-08-26T21:00:52Z

@disnet I can certainly make an attempt to split TypeNode into TsTypeNode and FlowTypeNode (there might be a bit more to this but that's the most important change I guess).

The Babel AST seems rather undetailed when it comes to Flow type annotations - it just says type FlowTypeAnnotation = Node and that's that. There's a bunch of other Flow-related nodes but I struggle with figuring out how they are related to one another.

I don't use Flow very much, so I'm quite ignorant. But I'm thinking I could either follow Flow documentation and create nodes for everything I see there, or I could follow Flow AST. The former is easier but may lead to imprecision and/or omissions. The latter sounds like fun since I don't know OCaml at all - the only issue may be that it will take a while until I'm done with it.

Another question: Is any sort of structural sharing across TsTypeNode and FlowTypeNode subclasses desirable? I'm thinking things might be simpler if I don't try to share anything but then there will clearly be some "duplication" since they ultimately have a lot in common.

…ameterDeclaration to make them (structurally) more alike

disnet · 2017-08-29T04:49:33Z

Ah yeah, the babylon spec is missing all the flow detail. We could probably figure it out from reading the plugin that generates the nodes though.

Is any sort of structural sharing across TsTypeNode and FlowTypeNode subclasses desirable?

I think no. Yeah we will probably have some duplication in the spec but that's fine I think; having them separate makes it easier if flow or ts evolves and forces a change to their respective AST.

btw, as long as we split the nodes (prefix ts specific nodes with Ts* and flow with Flow*) we probably can and should split the work into two PRs. No reason to block the ts nodes on figuring out the flow nodes.

slotik · 2017-09-10T18:25:53Z

I'm sorry for the long delay.

I added the Ts prefix where it seemed like a good idea. I didn't for example fork interface statements as such, instead I forked TypeElement. Let me know if anything needs to be adjusted.

I'm not aware of any outstanding issues in this PR - I'll continue working on it if/when I get more feedback.

As for Flow types, I'll take a look at the babel plugin and I can start adding them to a separate fork (which builds on the work here) within the following week.

disnet · 2017-09-10T22:03:23Z

I'm sorry for the long delay.

No worries, this is open source. It takes how long it takes 😄

I'll try and do a review soon and then we can get it merged and published under a pre-release tag. I suspect we'll find tweaks we want to make as we go about updating the parser.

disnet · 2017-09-10T22:04:30Z

src/term-spec.js

  body: FunctionBody;
 }

+declare export class AbstractMethodDefinition extends Term {


Should this be TsAbstractMethodDefinition?

Yes, that makes a lot of sense. The change is already in.

disnet · 2017-09-10T22:12:26Z

src/term-spec.js

  name: PropertyName;
  binding?: ObjectAssignmentTarget | ArrayAssignmentTarget | AssignmentTargetIdentifier | MemberAssignmentTarget | AssignmentTargetWithDefault;
 }



 // class
+
 declare export class ClassExpression extends Expression {


I don't love renaming super to heritageClauses. How about we split the TS stuff out into ClassExpression and TsClassExpression (with shared attributes in ClassExpressionBase)?

Alternatively we could type it as super: Expression | HeritageClause[] but in a given AST it will only ever be one or the other so it's nice to keep that clear with two different nodes.

I made the split of both ClassExpression and ClassDeclaration. Once that was done, it also seemed natural to split ClassElement, so I did that, too. The nice thing about the result is that it is backwards-compatible with the previous version of classes.

I also added ClassExpressionBase, ClassDeclarationBase and ClassElementBase - they only hold one field each but are perhaps still more preferable than duplicating those fields (and later triplicating for Flow* nodes).

…be support for such functions

…nBase

disnet

Great work! I'm going to merge but hold off on publishing until we get experience with it while implementing the changes in core.

cmcaine · 2017-10-02T19:24:46Z

What does the merge of this pull request mean for sweet.js?

Will I soon be able to run sjs example.ts.sjs > example.ts and have any macros in the first file expanded and the rest (including types) passed through unchanged?

Thanks!

disnet · 2017-10-03T00:10:00Z

That's the plan!

cmcaine · 2017-10-03T00:39:28Z

Excellent! Any idea when it will be ready?

disnet · 2017-10-03T01:48:29Z

When it’s ready 😜 I personally won’t have time to work on it for a while (life etc.) but am happy to review PRs.

…

On Mon, Oct 2, 2017 at 5:39 PM Colin Caine ***@***.***> wrote: Excellent! Any idea when it will be ready? — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#4 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAJOop_2Or11lRwyVFhsgvmtBsOCYXxks5soYJAgaJpZM4O8lms> .

alexshpilkin · 2018-05-27T19:30:42Z

@disnet Can you explain what's missing? (I know how frontends and Scheme macros work in general, but not any particulars about Sweet). I understand this PR added the AST definitions; what remains aside from a parser and an emitter in sweet-core?

Martin Slota added 7 commits August 19, 2017 01:04

Added classes for representing TypeScript-style type annotations

4bf673b

Resolved known issues around type nodes. Started using them in variab…

901e83a

…le and function declarations as well as call and arrow expressions. Added question token record to object properties. Stubbed out interfaces and type aliases.

Added support for TS-style ClassElements and associated modifiers

9800c22

Added interfaces. Added index signatures.

a744b32

Added type aliases and enums

b13a9da

Added 'type cast' expressions. Added type arguments in NewExpression …

38dadc3

…and CallExpressionE.

Cleanup in ParameterDeclaration. Added a couple of 'parent?' members,…

ff770d6

… mostly as documentation hints. These can be commented out or deleted later on.

slotik mentioned this pull request Aug 20, 2017

Support TypeScript/Flow type annotations sweet-js/sweet-core#482

Open

slotik commented Aug 20, 2017

View reviewed changes

Added readonly modifier to interface and class properties

6b8db62

disnet reviewed Aug 20, 2017

View reviewed changes

Added method return type. Added support for question token and type o…

1681ece

…f setter parameter. Made a separate AbstractMethodDefinition term.

slotik commented Aug 20, 2017

View reviewed changes

disnet mentioned this pull request Aug 21, 2017

Updating codegen sweet-js/sweet-core#742

Open

Martin Slota added 2 commits August 26, 2017 23:03

Removed semicolon class element

ddb75e8

Created common superclass for ParameterDeclaration and ConstructorPar…

09c054d

…ameterDeclaration to make them (structurally) more alike

Added 'Ts' prefix to (hopefully) all TypeScript-specific classes

4f93f74

disnet reviewed Sep 10, 2017

View reviewed changes

Split classes into regular and TypeScript classes

f688b6e

Martin Slota added 3 commits September 17, 2017 20:22

Removed generator flag from arrow functions as there doesn't seem to …

669893b

…be support for such functions

Added optional type parameters to methods and abstract methods

8363ccb

Simplified parent types using ClassDeclarationBase and ClassExpressio…

8f2270a

…nBase

slotik changed the title ~~Add support for type annotations~~ Add support for TypeScript type annotations Sep 17, 2017

disnet approved these changes Sep 24, 2017

View reviewed changes

disnet merged commit b2b6bea into sweet-js:master Sep 24, 2017

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add support for TypeScript type annotations #4

Add support for TypeScript type annotations #4

slotik commented Aug 20, 2017 •

edited

Loading

slotik Aug 20, 2017

disnet Aug 20, 2017

slotik Aug 20, 2017

slotik Aug 20, 2017

slotik Aug 20, 2017 •

edited

Loading

slotik Aug 20, 2017

slotik Aug 20, 2017

slotik Aug 20, 2017

slotik Aug 20, 2017 •

edited

Loading

disnet Aug 20, 2017

slotik Aug 20, 2017 •

edited

Loading

disnet Aug 20, 2017

slotik Aug 20, 2017

disnet commented Aug 22, 2017 •

edited

Loading

slotik commented Aug 26, 2017 •

edited

Loading

disnet commented Aug 29, 2017

slotik commented Sep 10, 2017

disnet commented Sep 10, 2017

disnet Sep 10, 2017

slotik Sep 17, 2017

disnet Sep 10, 2017

slotik Sep 17, 2017

disnet left a comment

cmcaine commented Oct 2, 2017

disnet commented Oct 3, 2017

cmcaine commented Oct 3, 2017 via email

disnet commented Oct 3, 2017 via email

alexshpilkin commented May 27, 2018


		// enum

		declare export class EnumDeclaration extends Statement {

Add support for TypeScript type annotations #4

Add support for TypeScript type annotations #4

Conversation

slotik commented Aug 20, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

slotik Aug 20, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

slotik Aug 20, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

slotik Aug 20, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

disnet commented Aug 22, 2017 • edited Loading

slotik commented Aug 26, 2017 • edited Loading

disnet commented Aug 29, 2017

slotik commented Sep 10, 2017

disnet commented Sep 10, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

disnet left a comment

Choose a reason for hiding this comment

cmcaine commented Oct 2, 2017

disnet commented Oct 3, 2017

cmcaine commented Oct 3, 2017 via email

disnet commented Oct 3, 2017 via email

alexshpilkin commented May 27, 2018

slotik commented Aug 20, 2017 •

edited

Loading

slotik Aug 20, 2017 •

edited

Loading

slotik Aug 20, 2017 •

edited

Loading

slotik Aug 20, 2017 •

edited

Loading

disnet commented Aug 22, 2017 •

edited

Loading

slotik commented Aug 26, 2017 •

edited

Loading