subject:"expanding comments proposal"

Re: expanding comments proposal

2016-10-22 Thread Gert Cuykens

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.

On Sat, Oct 22, 2016 at 3:46 PM, Bradley Meck <bradley.m...@gmail.com> wrote:
> I would like to note that TypeScript actually has runtime effects/syntax
> beyond just type annotation like how modules work:
> https://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.
>
> On Fri, Oct 21, 2016 at 10:11 PM, Gert Cuykens <gert.cuyk...@gmail.com>
> wrote:
>>
>> 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.
>>
>> On Sat, Oct 22, 2016 at 3:59 AM, Ron Buckton <ron.buck...@microsoft.com>
>> wrote:
>> >> From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of
>> >> Gert
>> >> Cuykens
>> >> Sent: Friday, October 21, 2016 4:56 PM
>> >> To: Tab Atkins Jr. <jackalm...@gmail.com>
>> >> Cc: Bruno Jouhier <bjouh...@gmail.com>; es-discuss > >> disc...@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: http://jsbin.com/xeticulini/edit?html,js
>> >
>> > Ron
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: expanding comments proposal

2016-10-22 Thread Bradley Meck

I would like to note that TypeScript actually has runtime effects/syntax
beyond just type annotation like how modules work:
https://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.

On Fri, Oct 21, 2016 at 10:11 PM, Gert Cuykens <gert.cuyk...@gmail.com>
wrote:

> 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.
>
> On Sat, Oct 22, 2016 at 3:59 AM, Ron Buckton <ron.buck...@microsoft.com>
> wrote:
> >> From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of
> Gert
> >> Cuykens
> >> Sent: Friday, October 21, 2016 4:56 PM
> >> To: Tab Atkins Jr. <jackalm...@gmail.com>
> >> Cc: Bruno Jouhier <bjouh...@gmail.com>; es-discuss  >> disc...@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: http://jsbin.com/xeticulini/edit?html,js
> >
> > Ron
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: expanding comments proposal

2016-10-21 Thread Gert Cuykens

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.

On Sat, Oct 22, 2016 at 3:59 AM, Ron Buckton <ron.buck...@microsoft.com> wrote:
>> From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Gert
>> Cuykens
>> Sent: Friday, October 21, 2016 4:56 PM
>> To: Tab Atkins Jr. <jackalm...@gmail.com>
>> Cc: Bruno Jouhier <bjouh...@gmail.com>; es-discuss > disc...@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: http://jsbin.com/xeticulini/edit?html,js
>
> Ron
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

RE: expanding comments proposal

2016-10-21 Thread Ron Buckton

> From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Gert
> Cuykens
> Sent: Friday, October 21, 2016 4:56 PM
> To: Tab Atkins Jr. <jackalm...@gmail.com>
> Cc: Bruno Jouhier <bjouh...@gmail.com>; es-discuss  disc...@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: 
http://jsbin.com/xeticulini/edit?html,js

Ron
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: expanding comments proposal

2016-10-21 Thread Gert Cuykens

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.

On Sat, Oct 22, 2016 at 1:24 AM, Tab Atkins Jr.  wrote:
> On Fri, Oct 21, 2016 at 3:20 PM, Gert Cuykens  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.
>
> ~TJ
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: expanding comments proposal

2016-10-21 Thread Tab Atkins Jr.

On Fri, Oct 21, 2016 at 3:20 PM, Gert Cuykens  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.

~TJ
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: expanding comments proposal

2016-10-21 Thread Gert Cuykens

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.

On Fri, Oct 21, 2016 at 11:57 PM, Tab Atkins Jr.  wrote:
> On Fri, Oct 21, 2016 at 2:46 PM, Gert Cuykens  wrote:
>> Exactly, here is a concrete ES2015 example
>> http://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
> .
>
> ~TJ
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: expanding comments proposal

2016-10-21 Thread Bruno Jouhier

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.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: expanding comments proposal

2016-10-21 Thread Tab Atkins Jr.

On Fri, Oct 21, 2016 at 2:46 PM, Gert Cuykens  wrote:
> Exactly, here is a concrete ES2015 example
> http://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
.

~TJ
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: expanding comments proposal

2016-10-21 Thread Gert Cuykens

Exactly, here is a concrete ES2015 example
http://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.

On Fri, Oct 21, 2016 at 7:37 PM, Bruno Jouhier  wrote:
> 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.
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: expanding comments proposal

2016-10-21 Thread Bruno Jouhier

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.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: expanding comments proposal

2016-10-21 Thread Bob Myers

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

On Fri, Oct 21, 2016 at 5:28 PM, Gert Cuykens 
wrote:

> 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.
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: expanding comments proposal

2016-10-21 Thread Gert Cuykens

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.

On Fri, Oct 21, 2016 at 3:35 AM, Isiah Meadows  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 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.
>
> [1]:
> https://tc39.github.io/ecma262/#sec-error-handling-and-language-extensions
>
> On Thu, Oct 20, 2016, 13:38 Gert Cuykens  wrote:
>>
>> Ok, what about a "use strict comments"; solution to prevent web breaking?
>>
>> On Thu, Oct 20, 2016 at 7:33 PM, Rick Waldron 
>> 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:
>> >
>> > https://github.com/rwaldron/tc39-notes/blob/master/es6/2014-09/sept-25.md#types
>> >
>> >
>> > Rick
>> >
>> > On Thu, Oct 20, 2016 at 1:14 PM Gert Cuykens 
>> > wrote:
>> >>
>> >> 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
>> >>
>> >> ```html
>> >> 
>> >> 
>> >>
>> >> 
>> >>   Test
>> >>   
>> >>   
>> >> 
>> >>
>> >> 
>> >>   
>> >> 
>> >>   :host {
>> >>   display: block;
>> >>   box-sizing: border-box;
>> >>   border: 1px solid red;
>> >>   margin: 13px 0;
>> >>   padding: 0 17px;
>> >>   }
>> >> 
>> >> Test 
>> >>   
>> >>   
>> >> 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)
>> >>   
>> >>   Hello World
>> >> 
>> >> 
>> >> ```
>> >>
>> >> ## Example typescript code
>> >>
>> >> ```html
>> >> 
>> >> 
>> >>
>> >> 
>> >>   Test
>> >>   
>> >>   
>> >> 
>> >>
>> >> 
>> >>   
>> >> 
>> >>   :host {
>> >>   display: block;
>> >>   box-sizing: border-box;
>> >>   border: 1px solid red;
>> >>   margin: 13px 0;
>> >>   padding: 0 17px;
>> >>   }
>> >> 
>> >> Test 
>> >>   
>> >>   
>> >> class HelloWorld extends HTMLElement {
>> >>   constructor() {
>> >>

Re: expanding comments proposal

2016-10-20 Thread Isiah Meadows

On Thu, Oct 20, 2016, 21:35 Isiah Meadows  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.


> 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.
>
> [1]:
> https://tc39.github.io/ecma262/#sec-error-handling-and-language-extensions
>
> On Thu, Oct 20, 2016, 13:38 Gert Cuykens  wrote:
>
> Ok, what about a "use strict comments"; solution to prevent web breaking?
>
> On Thu, Oct 20, 2016 at 7:33 PM, Rick Waldron 
> 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:
> >
> https://github.com/rwaldron/tc39-notes/blob/master/es6/2014-09/sept-25.md#types
> >
> >
> > Rick
> >
> > On Thu, Oct 20, 2016 at 1:14 PM Gert Cuykens 
> wrote:
> >>
> >> 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
> >>
> >> ```html
> >> 
> >> 
> >>
> >> 
> >>   Test
> >>   
> >>   
> >> 
> >>
> >> 
> >>   
> >> 
> >>   :host {
> >>   display: block;
> >>   box-sizing: border-box;
> >>   border: 1px solid red;
> >>   margin: 13px 0;
> >>   padding: 0 17px;
> >>   }
> >> 
> >> Test 
> >>   
> >>   
> >> 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)
> >>   
> >>   Hello World
> >> 
> >> 
> >> ```
> >>
> >> ## Example typescript code
> >>
> >> ```html
> >> 
> >> 
> >>
> >> 
> >>   Test
> >>   
> >>   
> >> 
> >>
> >> 
> >>   
> >> 
> >>   :host {
> >>   display: block;
> >>   box-sizing: border-box;
> >>   border: 1px solid red;
> >>   margin: 13px 0;
> >>   padding: 0 17px;
> >>   }
> >> 
> >> Test 
> >>   
> >>   
> >> 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)
> >>   
> >>   Hello World
> >> 
> >> 
> >> ```
> >> ___
> >> es-discuss mailing list
> >> es-discuss@mozilla.org
> >> https://mail.mozilla.org/listinfo/es-discuss
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: expanding comments proposal

2016-10-20 Thread Isiah Meadows

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.

[1]:
https://tc39.github.io/ecma262/#sec-error-handling-and-language-extensions

On Thu, Oct 20, 2016, 13:38 Gert Cuykens  wrote:

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

On Thu, Oct 20, 2016 at 7:33 PM, Rick Waldron 
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:
>
https://github.com/rwaldron/tc39-notes/blob/master/es6/2014-09/sept-25.md#types
>
>
> Rick
>
> On Thu, Oct 20, 2016 at 1:14 PM Gert Cuykens 
wrote:
>>
>> 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
>>
>> ```html
>> 
>> 
>>
>> 
>>   Test
>>   
>>   
>> 
>>
>> 
>>   
>> 
>>   :host {
>>   display: block;
>>   box-sizing: border-box;
>>   border: 1px solid red;
>>   margin: 13px 0;
>>   padding: 0 17px;
>>   }
>> 
>> Test 
>>   
>>   
>> 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)
>>   
>>   Hello World
>> 
>> 
>> ```
>>
>> ## Example typescript code
>>
>> ```html
>> 
>> 
>>
>> 
>>   Test
>>   
>>   
>> 
>>
>> 
>>   
>> 
>>   :host {
>>   display: block;
>>   box-sizing: border-box;
>>   border: 1px solid red;
>>   margin: 13px 0;
>>   padding: 0 17px;
>>   }
>> 
>> Test 
>>   
>>   
>> 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)
>>   
>>   Hello World
>> 
>> 
>> ```
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: expanding comments proposal

2016-10-20 Thread Gert Cuykens

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

On Thu, Oct 20, 2016 at 7:33 PM, Rick Waldron  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:
> https://github.com/rwaldron/tc39-notes/blob/master/es6/2014-09/sept-25.md#types
>
>
> Rick
>
> On Thu, Oct 20, 2016 at 1:14 PM Gert Cuykens  wrote:
>>
>> 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
>>
>> ```html
>> 
>> 
>>
>> 
>>   Test
>>   
>>   
>> 
>>
>> 
>>   
>> 
>>   :host {
>>   display: block;
>>   box-sizing: border-box;
>>   border: 1px solid red;
>>   margin: 13px 0;
>>   padding: 0 17px;
>>   }
>> 
>> Test 
>>   
>>   
>> 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)
>>   
>>   Hello World
>> 
>> 
>> ```
>>
>> ## Example typescript code
>>
>> ```html
>> 
>> 
>>
>> 
>>   Test
>>   
>>   
>> 
>>
>> 
>>   
>> 
>>   :host {
>>   display: block;
>>   box-sizing: border-box;
>>   border: 1px solid red;
>>   margin: 13px 0;
>>   padding: 0 17px;
>>   }
>> 
>> Test 
>>   
>>   
>> 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)
>>   
>>   Hello World
>> 
>> 
>> ```
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: expanding comments proposal

2016-10-20 Thread Rick Waldron

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:
https://github.com/rwaldron/tc39-notes/blob/master/es6/2014-09/sept-25.md#types


Rick

On Thu, Oct 20, 2016 at 1:14 PM Gert Cuykens  wrote:

> 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
>
> ```html
> 
> 
>
> 
>   Test
>   
>   
> 
>
> 
>   
> 
>   :host {
>   display: block;
>   box-sizing: border-box;
>   border: 1px solid red;
>   margin: 13px 0;
>   padding: 0 17px;
>   }
> 
> Test 
>   
>   
> 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)
>   
>   Hello World
> 
> 
> ```
>
> ## Example typescript code
>
> ```html
> 
> 
>
> 
>   Test
>   
>   
> 
>
> 
>   
> 
>   :host {
>   display: block;
>   box-sizing: border-box;
>   border: 1px solid red;
>   margin: 13px 0;
>   padding: 0 17px;
>   }
> 
> Test 
>   
>   
> 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)
>   
>   Hello World
> 
> 
> ```
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

expanding comments proposal

2016-10-20 Thread Gert Cuykens

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

```html




  Test
  
  



  

  :host {
  display: block;
  box-sizing: border-box;
  border: 1px solid red;
  margin: 13px 0;
  padding: 0 17px;
  }

Test 
  
  
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)
  
  Hello World


```

## Example typescript code

```html




  Test
  
  



  

  :host {
  display: block;
  box-sizing: border-box;
  border: 1px solid red;
  margin: 13px 0;
  padding: 0 17px;
  }

Test 
  
  
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)
  
  Hello World


```
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: expanding comments proposal

Re: expanding comments proposal

Re: expanding comments proposal

RE: expanding comments proposal

Re: expanding comments proposal

Re: expanding comments proposal

Re: expanding comments proposal

Re: expanding comments proposal

Re: expanding comments proposal

Re: expanding comments proposal

Re: expanding comments proposal

Re: expanding comments proposal

Re: expanding comments proposal

Re: expanding comments proposal

Re: expanding comments proposal

Re: expanding comments proposal

Re: expanding comments proposal

expanding comments proposal

18 matches

Site Navigation

Mail list logo

Footer information