Re: Re: Proposal static type constraints features
I also want to see a better way. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Proposal static type constraints features
The default alternative is "neither" - I think something as fundamental as type annotations would need to have intuitive and conflict-free syntax, and absolutely would have a way to work cross-realm with both objects and primitives, to both distinguish between them and to allow both (in the case of primitives other than null/undefined). On Sun, Jun 3, 2018 at 10:50 PM, YU HengChun wrote: > Or enable both versions at the same time? > ___ > 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: Re: Proposal static type constraints features
Or enable both versions at the same time? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Proposal static type constraints features
The typeof version does have this problem. So, how to choose? Maintain the original semantics of the word? Or define new semantics for void? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Proposal static type constraints features
So now for every type annotation, someone has to add `&& undefined`? That
seems like a lot of confusing boilerplate to have to add.
On Sun, Jun 3, 2018 at 10:39 PM, YU HengChun wrote:
> This is easy to solve, we change the word. But the code will be longer.
>
> The original:
>
> ```js
> function f(x) {
> return typeof x !== 'string' || typeof x === 'undefined';
> }
> ```
>
> The proposal: typeof version
>
> ```js
> function f(x = typeof(String) && undefined ) { // Attention can not be
> omitted: && undefined
> void typeof(Boolean); // or only: typeof(Boolean);
> return typeof x !== 'string' || typeof x === 'undefined';
> }
> ```
>
> 这很容易解决, 换个单词就行. 但是代码会更长.
>
>
> ___
> 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: Re: Proposal static type constraints features
This is easy to solve, we change the word. But the code will be longer.
The original:
```js
function f(x) {
return typeof x !== 'string' || typeof x === 'undefined';
}
```
The proposal: typeof version
```js
function f(x = typeof(String) && undefined ) { // Attention can not be omitted:
&& undefined
void typeof(Boolean); // or only: typeof(Boolean);
return typeof x !== 'string' || typeof x === 'undefined';
}
```
这很容易解决, 换个单词就行. 但是代码会更长.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Proposal static type constraints features
There's the separate issue that "void" in no way connotes types, so that
word wouldn't likely be acceptable, because it has no relevant meaning.
On Sun, Jun 3, 2018 at 10:27 PM, YU HengChun wrote:
> You mean this...
>
> The original:
>
> ```js
> function f(x) {
> return typeof x !== 'string' || typeof x === 'undefined';
> }
> ```
>
> The proposal:
>
> ```js
> function f(x = void String) {
> void Boolean; // The complete code should be like this
> return typeof x !== 'string' || typeof x === 'undefined';
> }
> ```
>
> Thank you, you actually provided an example to prove that the proposal is
> conflict-free.
>
> Test code is casually written, the results of these two versions will be
> consistent.
>
>
> 我得谢谢你的关注(真的, 这样才可以有更多的验证).
> 你刚好提供了一个例子证明我的提案是无冲突的.
> 随便写测试代码吧, 这两个版本的结果完全一致.
>
>
> ___
> 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: Re: Proposal static type constraints features
You mean this...
The original:
```js
function f(x) {
return typeof x !== 'string' || typeof x === 'undefined';
}
```
The proposal:
```js
function f(x = void String) {
void Boolean; // The complete code should be like this
return typeof x !== 'string' || typeof x === 'undefined';
}
```
Thank you, you actually provided an example to prove that the proposal is
conflict-free.
Test code is casually written, the results of these two versions will be
consistent.
我得谢谢你的关注(真的, 这样才可以有更多的验证).
你刚好提供了一个例子证明我的提案是无冲突的.
随便写测试代码吧, 这两个版本的结果完全一致.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Proposal static type constraints features
`function f(x = void String) { return typeof x !== 'string' || typeof x ===
'undefined'; } assert(f(3))` is code that might stop working properly if
`void String` changes from being `undefined` to literally anything else.
2018-06-03 22:01 GMT-07:00 YU HengChun :
> Strictly speaking, the behavior is different.
>
> However, can you provide me with a real, conflicting example?
>
> Or you give me an example, I write a version of the proposal, you can test
> whether it is really harmful.
>
>
> If it is finally proved that the semantics are different, but it is indeed
> harmless, it is normal to add new semantics.
>
> In fact ECMAScript has been enriching semantics.
>
> 严格意义上讲, 这个提案的确产生了不同的语义行为.
>
> 但是, 你能举一个真实的例子来说明这个提案会产生为哈么?
>
> 或者, 你给我一个例子, 我用提案的写法写一个版本, 你可以测试下是否真的有危害.
>
> 如果最终证明虽然语义不同, 但的确是无危害性的, 那么添加新的语义是很正常的.
>
> 事实上 ECMAScript 就是在不断的丰富语义啊.
>
> ___
> 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: Re: Proposal static type constraints features
Strictly speaking, the behavior is different. However, can you provide me with a real, conflicting example? Or you give me an example, I write a version of the proposal, you can test whether it is really harmful. If it is finally proved that the semantics are different, but it is indeed harmless, it is normal to add new semantics. In fact ECMAScript has been enriching semantics. 严格意义上讲, 这个提案的确产生了不同的语义行为. 但是, 你能举一个真实的例子来说明这个提案会产生为哈么? 或者, 你给我一个例子, 我用提案的写法写一个版本, 你可以测试下是否真的有危害. 如果最终证明虽然语义不同, 但的确是无危害性的, 那么添加新的语义是很正常的. 事实上 ECMAScript 就是在不断的丰富语义啊. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Proposal static type constraints features
What about existing code that might use `void` in a way that's confused
with your static type proposal? Suddenly it would start behaving
differently.
On Sun, Jun 3, 2018 at 8:32 PM, YU HengChun wrote:
> > A separate question is, how would String cover strings across realms,
> considering that 'abc' instanceof String already returns false even in the
> same realm?
>
> There is no such way in the proposal.
>
> 提案中没有这样的写法.
>
> The real purpose of the expression in void is not the operation.
> It is description for typing, the literal semantics.
> It is compatible with the old engine. Even if it is operated, it will not
> have side effects.
>
> The new engine will extract the type description, and will not operate on
> it.
>
> void 中的表达式不是用来计算的, 是为了描述类型, 只是为了兼容陈旧的引擎, 在陈旧的引擎中它也是合法的, 老引擎里面它会被计算,
> 但不会有副作用.
>
> 新引擎会提取其中的类型描述, 不会去运算它.
>
>
> So, The correct way is:
>
> ```js
> function CustomString(x = void( Object instanceof String) || 'abc' ) {
> // ...
> }
> ```
>
> The form `Object instanceof TYPE` is for backward compatibility.
>
>
>
> ___
> 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: Re: Proposal static type constraints features
> A separate question is, how would String cover strings across realms,
> considering that 'abc' instanceof String already returns false even in the
> same realm?
There is no such way in the proposal.
提案中没有这样的写法.
The real purpose of the expression in void is not the operation.
It is description for typing, the literal semantics.
It is compatible with the old engine. Even if it is operated, it will not have
side effects.
The new engine will extract the type description, and will not operate on it.
void 中的表达式不是用来计算的, 是为了描述类型, 只是为了兼容陈旧的引擎, 在陈旧的引擎中它也是合法的, 老引擎里面它会被计算, 但不会有副作用.
新引擎会提取其中的类型描述, 不会去运算它.
So, The correct way is:
```js
function CustomString(x = void( Object instanceof String) || 'abc' ) {
// ...
}
```
The form `Object instanceof TYPE` is for backward compatibility.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Proposal static type constraints features
To clarify from above; it's almost certainly not going to be web compatible
to change how `void` works in expressions, so if another alternative isn't
viable, then it's kind of a nonstarter.
A separate question is, how would `String` cover strings across realms,
considering that `'abc' instanceof String` already returns `false` even in
the same realm?
On Sun, Jun 3, 2018 at 10:46 AM, YU HengChun wrote:
> > ```js
> > function CustomNumber(x = void([Number, mod.BigNumber]) || 42) {
> > // ...
> > }
> > ```
> >
> > which is arguably awkward.
>
> Easy, change the word well.
>
> ```js
> function CustomNumber(x = typeof([Number, mod.BigNumber]) && 42) {
> // ...
> }
> ```
>
>
> ___
> 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: Re: Proposal static type constraints features
> ```js
> function CustomNumber(x = void([Number, mod.BigNumber]) || 42) {
> // ...
> }
> ```
>
> which is arguably awkward.
Easy, change the word well.
```js
function CustomNumber(x = typeof([Number, mod.BigNumber]) && 42) {
// ...
}
```
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Proposal static type constraints features
Consider the significance of this proposal from another perspective: 1. It is a native ECMAScript 1. It can be regarded as an enhanced version of asm.js 1. It has always existed, but it has been neglected and has not been fully utilized. 1. The cost is much lighter than adding a new grammar 1. After the proposal is passed, it will seamlessly connect with WebAssembly 从另外的角度考虑这个提案的意义: 1. 它是原生的 ECMAScript 1. 这几乎就是 asm.js 的加强版啊 1. 本来就一直存在, 只是被忽略了, 未被充分利用 1. 成本上比添加新语法要轻量的多 1. 这个提案被通过后将和 WebAssembly 无缝对接 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Proposal static type constraints features
ps: Accidentally, the email just sent was sent to isiah. This is a copy TS/Flow is better about static type constraints. If the syntax of TS/Flow can enter the proposal, I will not submit this proposal. The only benefits of this grammar are: Even if the proposal cannot be passed, it will still work, at least for the type description. So, in reality, this proposal will still be used. Of course, additional tools are needed. At least code is not to tranfrom, is standard, legal, and can run ECMAScript. 这个语法真的不比 TS/Flow 好啥. 如果类似 TS/Flow 的语法能进入讨论阶段, 我也不用提交这个提案了. 该提案唯一的优势是: 即时因为某种原因无法通过, 至少类型描述部分是有效的. 所以, 在现实中, 这个提案还是会被使用, 因为它是合法的代码. 当然, 如果要让静态类型约束生效, 还需额外的工具配合(也是不想写这个工具, 我才提交提案的啊). 无论如何, 代码是合法的, 可运行的标准 ECMAScript, 再也不用转换了. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Proposal static type constraints features
How this this syntax more useful than one derived from TS/Flow, like `x: Foo`?
-
Isiah Meadows
m...@isiahmeadows.com
www.isiahmeadows.com
On Sun, Jun 3, 2018 at 11:48 AM, YU HengChun wrote:
> Update
>
>
> ## Compatibility
>
> For safety, it may be a good idea to use it with default values.
>
> ```js
> let
> isUndefined = void Number,
> // Static type constraint does not take effect
> isNumberUndefined = void(Number)|undefined;
> // Static type constraint take effect
>
> ```
>
> ## Pending
>
> I'm not sure if it is necessary to support multiple levels of nesting
>
> ```js
> class ConfigType {
> constructor() {
> void {
> version: Number,
> encodeNames: Boolean,
> lines: [String],
> filename: String,
> linker: undefined | { // Need support?
> statics: { [String]: Number },
> }
> };
> }
> }
> ```
>
>
>
> ___
> 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: Re: Proposal static type constraints features
Update
## Compatibility
For safety, it may be a good idea to use it with default values.
```js
let
isUndefined = void Number,
// Static type constraint does not take effect
isNumberUndefined = void(Number)|undefined;
// Static type constraint take effect
```
## Pending
I'm not sure if it is necessary to support multiple levels of nesting
```js
class ConfigType {
constructor() {
void {
version: Number,
encodeNames: Boolean,
lines: [String],
filename: String,
linker: undefined | { // Need support?
statics: { [String]: Number },
}
};
}
}
```
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Proposal static type constraints features
我的英文水平太 low, 辅助机器翻译, 看双语版吧. __O_O__
To avoid misunderstanding caused by machine translation, I use bilingual.
> is already valid syntax in ECMAScript, and you can't change its semantics
> willy-nilly
首先, 这个提案要求更改语义才能实现静态类型. 如果这是绝对不允许的, 那这个提案应该被拒绝.
First of all, This proposal requires changing the semantics to achieve static
typing.
If this is absolutely not allowed, then this proposal should be rejected.
> How do you ….. errors?
过去可能有人这样用, 但是, 谁写代谁负责, 即便这个提案不被通过, 该发生的错误还是会发生.
Someone may have used it in the past, but whoever writer is responsible for
it. Even if this proposal is not passed, the mistake will still happen.
> Also ….. constranints?
默认值还是原来的标准.
The default value is still the original standard.
类型约束是我的提案, 可以附加到默认值之前.
The type constraint is my proposal and can be appended to the default value.
其实他们是独立的两部分, 只是用运算符 '||' 把他们合法的连接起来.
They are two separate parts, and they are legally connected using operator '||'
for backward compatibility.
> which means …..to do something like?
这个提案只是描述了如何写静态类型约束.
This proposal just describes how to write static type constraints.
现实中由编译器负责把静态类型约束部分抽离出来, 不参与默认值运算.
In reality, the compiler is responsible for pulling out the static type
constraint part, Does not participate in the default operation.
这个提案和 asm.js 的做法非常相似, 并且增大了使用范围.
This proposal is very similar to the asm.js approach and increases the scope of
use.
不只是在初始化时标记内建类型, 更广泛的应用于所有定义的类型, 所有初始化和声明.
Not only is the built-in type flagged at initialization,
it is more widely applied to all defined types, all initializations and
declarations.
E.g: asm.js
```js
function geometricMean(start, end) {
start = start|0; // start has type int
end = end|0; // end has type int
return +exp(+logSum(start, end) / +((end - start)|0));
}
```
Proposal:
```js
import types form 'your-types';
function geometricMean(start=void(types.int), end=void(types.int)) {
return +exp(+logSum(start, end) / +((end - start)|0));
}
```
If the proposal passes, then:
```js
geometricMean('0','1'); // Throws type error
```
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
