Discuss
  • expanding comments proposal

expanding comments proposal

# Gert Cuykens (8 years ago)

Currently there are two ways to make comments // and /**/ in Ecma262. I think if Ecma262 has a broader way of implementing comments it can open up the door for third party type checkers and leave the burden onto others without the need for transpiling.

I am looking into how close ES20XX syntax for example compares to typescript syntax. A Ecma262 compiler doesn't need to look at the typings at all, just be smart enough to ignore typings. Is the Ecma262 community willing to look at a few syntax notations that a Ecma262 parser should ignore?

If there is no objection at first look I am going to put in the effort to try to cover a complete syntax that extends // and /**/ so others can use that to implement for example a type checker? Notice that I am not asking for type checking itself, just expanding // and /**/ that makes it possible for others to do for example type checking and maintain a clean syntax look of their code.

Example ES2015 code

<!DOCTYPE html>
<html >

<head>
  <title>Test</title>
  <meta http-equiv="X-UA-Compatible" content="IE=edge" />
  <meta name="viewport" content="width=device-width,
initial-scale=1.0, minimum-scale=1.0" />
</head>

<body>
  <template>
    <style>
      :host {
          display: block;
          box-sizing: border-box;
          border: 1px solid red;
          margin: 13px 0;
          padding: 0 17px;
      }
    </style>
    <p>Test <slot></slot></p>
  </template>
  <script>
    class HelloWorld extends HTMLElement {
      constructor() {
        super()
        const t = document.querySelector('template')
        const instance = t.content.cloneNode(true)
        const shadowRoot = this.attachShadow({ mode: 'open' })
        shadowRoot.appendChild(instance)
      }
    }
    customElements.define('hello-world', HelloWorld)
  </script>
  <hello-world>Hello World</hello-world>
</body>
</html>

Example typescript code

<!DOCTYPE html>
<html >

<head>
  <title>Test</title>
  <meta http-equiv="X-UA-Compatible" content="IE=edge" />
  <meta name="viewport" content="width=device-width,
initial-scale=1.0, minimum-scale=1.0" />
</head>

<body>
  <template>
    <style>
      :host {
          display: block;
          box-sizing: border-box;
          border: 1px solid red;
          margin: 13px 0;
          padding: 0 17px;
      }
    </style>
    <p>Test <slot></slot></p>
  </template>
  <script type="ts/module">
    class HelloWorld extends HTMLElement {
      constructor() {
        super()
        const t:type1 = document.querySelector('template')
        const instance:type2 = t.content.cloneNode(true)
        const shadowRoot:type3 = this.attachShadow({ mode: 'open' })
        shadowRoot.appendChild(instance)
      }
    }
    customElements.define('hello-world', HelloWorld)
  </script>
  <hello-world>Hello World</hello-world>
</body>
</html>
# Rick Waldron (8 years ago)

Overloading comments is not likely to be accepted as a new feature; doing so could be dramatically "web breaking".

You may be interested in this: rwaldron/tc39-notes/blob/master/es6/2014-09/sept-25.md#types

# Gert Cuykens (8 years ago)

Ok, what about a "use strict comments"; solution to prevent web breaking?

# Isiah Meadows (8 years ago)

Please, let's not add a new pragma to the language. "use strict" was a hack to enable some sanity while still remaining back-compatible, but it's not something we should repeat IMHO. (TC39 unanimously

I would, on the other hand, strongly support dropping most of the restriction in section 16, third paragraph 1 and moving the remaining bits to Annex B, namely that conforming implementations are not allowed to report early errors beyond what's specified as such in the spec. (This is why TypeScript emits code by default even in the presence of static type errors. It remains a superset this way.) That would make it much easier to experiment with typed JavaScript at the engine level, and it would give much more freedom to type checkers.

On Thu, Oct 20, 2016, 13:38 Gert Cuykens <gert.cuykens at gmail.com> wrote:

Ok, what about a "use strict comments"; solution to prevent web breaking?

On Thu, Oct 20, 2016 at 7:33 PM, Rick Waldron <waldron.rick at gmail.com>

wrote:

Overloading comments is not likely to be accepted as a new feature; doing

so

could be dramatically "web breaking".

You may be interested in this:

rwaldron/tc39-notes/blob/master/es6/2014-09/sept-25.md#types

# Isiah Meadows (8 years ago)

On Thu, Oct 20, 2016, 21:35 Isiah Meadows <isiahmeadows at gmail.com> wrote:

Please, let's not add a new pragma to the language. "use strict" was a hack to enable some sanity while still remaining back-compatible, but it's not something we should repeat IMHO. (TC39 unanimously

...I sent this earlier than I intended

What I meant was that TC39 unanimously agrees that adding pragmas are a bad idea, and several feel they're ugly.

# Gert Cuykens (8 years ago)

I agree with that a new pragma decision being a bad idea. Sometimes it's hard to have a full picture on the benefits, I just hope that everybody understand even if they never used a transpiler of any kind before that tooling gets complicated. If for example a typescript document can get evaluated by a browser by just ignoring the typings that doesn't introduce any new functionality to Ecma262 itself, tooling would be made much easier. No copying into new files, no livereload problems, no source maps, no bundling needed etc. It will just giving the freedom for supersets like typescript or any other language superset to keep a clean syntax and share transparent information with other developers without the need for all the extra tools required. Note that I am using typescript just as a example because it is one of does languages that tries very hard to just be a superset, it will always compile plain javascript just fine. We just have to define or set the rules what syntax can be a superset.

# Bob Myers (8 years ago)

Perhaps you could clarify your proposal, because I for one don't get it.

Are you talking about some new, additional commenting/pragma mechanism? Are you talking about some kind of extension to existing comments, like triple slashes? You say new pragmas are a bad idea--yet isn't that what your proposal is for? How would this work with TS? I don't see how your examples fit into your proposals.

Bob

# Bruno Jouhier (8 years ago)

Not sure I'm getting it either.

One interpretation would be to have ES20?? treat TypeScript syntax extensions as comments. This would allow TS code to be directly consumed by JS engines, without a transpiler.

The semantics of the TS type annotations could be standardized separately (and later). From a runtime perspective, they are just comments.

But I'm not sure that this is what the OP meant.

# Gert Cuykens (8 years ago)

Exactly, here is a concrete ES2015 example jsbin.com/ruqekam/edit?html,output Now just add a simple typescript type to any of the variables and notice everything breaks. If ES2015 would be smart enough to ignore the typings I can use a simple jsbin to share my code with others without any transpiling. I want to avoid making this a typescript specific thing but just want to point out that Ecma262 can be made more flexible to allow some supper set syntax that browser vendors can simply ignore but editors like vscode can use it for intellisense because it recognizes the extra syntax as typescript for example.

# Tab Atkins Jr. (8 years ago)

On Fri, Oct 21, 2016 at 2:46 PM, Gert Cuykens <gert.cuykens at gmail.com> wrote:

Exactly, here is a concrete ES2015 example jsbin.com/ruqekam/edit?html,output Now just add a simple typescript type to any of the variables and notice everything breaks. If ES2015 would be smart enough to ignore the typings I can use a simple jsbin to share my code with others without any transpiling. I want to avoid making this a typescript specific thing but just want to point out that Ecma262 can be made more flexible to allow some supper set syntax that browser vendors can simply ignore but editors like vscode can use it for intellisense because it recognizes the extra syntax as typescript for example.

Okay, so it sounds like your proposal is that ES allow the TypeScript syntax of writing variables declarations as "name:type", and treat the :type part as a comment?

If you're interested in "typing that look like comments", you can do that today; Python2 defines a reasonable syntax in Pep 484 www.python.org/dev/peps/pep-0484/#suggested-syntax-for-python-2-7-and-straddling-code.

# Bruno Jouhier (8 years ago)

Making things seamless for TS would mean more than just accepting the name: type syntax and ignoring its : type part. ES would also need to accept other syntax from TS: expr as type, type T = ..., declare ..., class C implements I, etc. A half job would not cut it because you quickly end up using all these constructs when you develop in TS.

I'm not saying this would be a bad thing (I'd love to have it) but this is going a bit beyond expanding comments syntax.

Introducing yet another comments syntax which is not understood by TS would not help at all, as we would still need a transpiler.

# Gert Cuykens (8 years ago)

First I would like to see if we can agree on the term superset. Like the question is typescript a superset of ES? As you pointed out there are many comment like solutions like jsdoc or like your pep 484 suggestion. But then a superset get narrowed down to // and /**/ which is fine but that means typescript doesn't come close as a super set and can never be used in jsbin directly for example.

So the big question is can we agree on a superset that stretches the boundaries so that typescript would fall under that category. If for example certain typescript syntax is too brought I can ask the typescript community if they can adjust their compiler in the future that is compatible with the Ecma superset specifications.

# Tab Atkins Jr. (8 years ago)

On Fri, Oct 21, 2016 at 3:20 PM, Gert Cuykens <gert.cuykens at gmail.com> wrote:

First I would like to see if we can agree on the term superset. Like the question is typescript a superset of ES? As you pointed out there are many comment like solutions like jsdoc or like your pep 484 suggestion. But then a superset get narrowed down to // and /**/ which is fine but that means typescript doesn't come close as a super set and can never be used in jsbin directly for example.

Supersets have more stuff than the base. Anything that's a superset syntax-wise will never be usable in places that expect base grammar; the extra stuff will be a syntax error.

So the big question is can we agree on a superset that stretches the boundaries so that typescript would fall under that category. If for example certain typescript syntax is too brought I can ask the typescript community if they can adjust their compiler in the future that is compatible with the Ecma superset specifications.

Can you actually explain what you're asking for, with specifics? So far all i can divine is that you want JS to allow some TypeScript-specific syntax (and treat it as comments?), but I don't know what syntax you're asking for. All you've done so far is provide TypeScript snippets for us to look at.

# Gert Cuykens (8 years ago)

There are two reasons for that, one is am not a typescript expert but if you want the complete typescript syntax set I can look it up and try to summarize the complete syntax and find some typescript expert who can help me on this. Two I dont want to exclude other languages that I dont know off and make them feel like they don't count. But I admit my end goal for me personally is indeed aimed to typescript because I use it the most.

# Ron Buckton (8 years ago)

From: es-discuss [mailto:es-discuss-bounces at mozilla.org] On Behalf Of Gert Cuykens Sent: Friday, October 21, 2016 4:56 PM To: Tab Atkins Jr. <jackalmage at gmail.com> Cc: Bruno Jouhier <bjouhier at gmail.com>; es-discuss <es- discuss at mozilla.org> Subject: Re: expanding comments proposal

There are two reasons for that, one is am not a typescript expert but if you want the complete typescript syntax set I can look it up and try to summarize the complete syntax and find some typescript expert who can help me on this. Two I dont want to exclude other languages that I dont know off and make them feel like they don't count. But I admit my end goal for me personally is indeed aimed to typescript because I use it the most.

If this is aimed at the fact that you would like to be able to paste TypeScript code into JSBin, please be aware that JSBin does have support for TypeScript: jsbin.com/xeticulini/edit?html,js

Ron

# Gert Cuykens (8 years ago)

Apparently you can, I used jsbin to show the compiler errors which would be the same if I gave you a html file. Notice that web components (polymer to be more exact) tend to use inline scripting so you can program more declarative and that the html template you are using is close to the js code for that specific part, not in a different file.

A complete other benefit would be the npm world can contain pure typescript and you only need a nodejs compiler once nodejs support es2015 modules. Now you need to make type definitions for your npm package. I also believe the adoption rate of typescript would increase allot. I know that I can't convince a js specialist into typescript because they make far less mistakes then I do, but for beginners its highly recommended they start with something like typescript before you take off the typing training wheels and let them do pure js.

I think the Ecma262 community would benefit if they can tell the world, look we will focus on the low level part and if you want typings fine, here is the superset syntax specification to do so but don't bother us again for typings go complain to Ecma26X :) It's going to relieve friction between typescript and narrows the Ecma262 down to the essentials without sacrificing blocking evolution in typings which is essentially just syntax sugar anyway and never needed as a essential part of Ecmascript. Or to phrase it differently, out source the typings by making a agreement how to do so.

# Bradley Meck (8 years ago)

I would like to note that TypeScript actually has runtime effects/syntax beyond just type annotation like how modules work: www.typescriptlang.org/docs/handbook/modules.html . I don't think it is realistic to treat things that affect runtime/import/export/etc. to be treated as comments and expect things to just work.

# Gert Cuykens (8 years ago)

I don't know for sure if these runtime effects can be ignored when we just parsing the code, but I can ask typescript to join the discussion once we have somewhat a basic agreement that the concept of a syntax superset is worth a deeper investigation.