Re: await on synchronous functions

[Mark S. Miller]

On Sun, Jul 19, 2015 at 10:16 AM, Bergi a.d.be...@web.de wrote:

 Mark S. Miller wrote:

  We've talked about allowing await at the top level of modules, I think so
 that the await continuation could proceed after the synchronous part of
 the
 load. I am unclear on the details and cannot reconstruct a sensible story
 from memory.


 I'd love to see that, using `await` in my main.js (or app.js or whatever
 it is called), so that I can write scripts using asynchronous functions
 without having to wrap everything in an IEAFE (immediately-executed
 asynchronous function expression).


Cute. How do you pronounce it?



 Not sure whether such syntax might also be used with asynchronous module
 loaders, but at least at the top level of an app this would certainly be
 useful.

 While `JSON.parse(await fs.readFile(options.json))` could trivially be
 replaced with `fs.readFileSync`, such might not be the case for `await
 db.readTable(config)`.

 Regards,
  Bergi


-- 
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES8 Proposal: Optional Static Typing

[Herby Vojčík]

Filip Pizlo wrote:

Hi Brandon,

Thanks for writing this up!

My personal feeling is that I’d rather ES not have static typing of this
form. I believe it makes the language substantially more complex, and to
me it feels best to try to minimize the growth of the language in order
to ensure that those things that we do add are added in a compatible and
sound way. Also, I wonder if static typing wouldn’t work out better if
instead of extending ES, you found a way to instead make wasm
(https://www.w3.org/community/webassembly/) powerful enough to handle
the language that you want. The benefit of that route is that (1) there


+1


is already support behind wasm and what I see as a broad desire to
enable wasm to handle statically-typed object-oriented/functional
languages, and (2) it’s a clean slate, so a proposal doesn’t have to
worry about the compatibility issues.


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

Re: ES8 Proposal: Optional Static Typing

[Herby Vojčík]

Two things:

I heard Gilad Bracha in ECOOP to say [paraphrase] optional typing is 
great to help with documentation, and to help the tools; but it should 
not touch the runtime. This is what I take for my own as well, nicely 
said. Your overload proposition, though, changes the language so that 
this would need to touch the runtime. It seems there are two distinct 
view on bringing static typing in to dynamically-typed languages: one of 
them in line with the aformentioned, the other taking over the semantic 
and runtime as well. There are also two terms: optional typing and 
gradual typing. I really don't know if those are defined precisely, 
but there seemed to be a sentiment that optional typing is the 
Gilad-Brachaish Strongtalk-like view, and gradual typing is the view 
that actually changes the semantics of the language and the runtime. 
What I wanted to say, is, that maybe this thread should be called ES8 
Proposal: Gradual Static Typing.


And I forgot the second one. Though I personally think changing the 
semantics (do gradual typing) would change the language to something 
very different and may complicate the good old duck-typing way of doing 
things. Truly optional typing, in the sense of help the tools and 
document is good, though. But it is completely different debate (some 
foods for though: 1. We have JSDoc which already does that - we can 
type-annotate and tools do the work; 2. An eye-opener is to learn that 
there is distinction between nominal types and structural types. Does it 
not suit ES, as a duck-typing language, to have optional structural 
typing instead of optional nominal typing?).


Herby


Brandon Andrews wrote:

ES8 Proposal: Optional Static Typing

It was once said by Brendan Eich that 'Types are hard. This doesn't mean no, 
never.' It's been a while since ES4. With ES6's TypedArrays and classes finalized 
and ES7 SIMD getting experimental tests, ECMAScript is in a good place to finally discuss 
types again. The demand for types as a different approach to code has been so strong in 
the past few years that separate languages have been created to deal with the perceived 
shortcomings. Types won't be an easy discussion, nor an easy addition, since they touch a 
large amount of the language; however, they are something that needs rigorous discussion. 
I'm hoping this initial proposal can be a way of pushing the ball forward. Turning this 
into an official proposal discussed by TC39 is the goal. This could very well be most of 
ES8 due to the complexity.

Since it would be potentially years before this would be implemented this proposal 
includes a new keyword enum for enumerated types and the following types:

number
bool
string
object
int8/16/32/64
uint8/16/32/64
bignum
float16/32/64/80/128
decimal32/64/128
int8x16/16x8/32x4/64x2/8x32/16x16/32x8/64x4
uint8x16/16x8/32x4/64x2/8x32/16x16/32x8/64x4
float32x4/64x2/32x8/64x4
rational
complex
any
void

These types bring ECMAScript in line or surpasses the type systems in most 
languages. For developers it cleans up a lot of the syntax, as described later, 
for TypedArrays, SIMD, and working with number types (floats vs signed and 
unsigned integers). It also allows for new language features like function 
overloading and a clean syntax for operator overloading. For implementors, 
added types offer a way to better optimize the JIT when specific types are 
used. For languages built on top of Javascript this allows more explicit type 
usage and closer matching to hardware.

In theory the following current keywords could be deprecated in the long-term: 
Boolean, Number, String, Object, and the TypedArray objects. Their methods and 
features would be rolled into the new type system.

One of the first complications with types is typeof's behavior. All of the above types 
would return their string conversion including bool. (In my experience 
boolean is seen as verbose among C++ and C# developers. Breaking this part of 
Java's influence probably wouldn't hurt to preserve consistency for the future).

The next few parts cover type features that should be supported. The examples 
aren't meant to be exhaustive but rather show parts of the language that 
require new grammar and discussion.

Support for nullable types.

var foo:uint8? = null;

Support for resizable typed arrays.

var foo:uint8[];
foo.push(1);
var bar:uint8[] = [1, 2, 3, 4];

Support for fixed-length typed arrays:

var foo:uint8[4];
foo.push(0); // invalid
foo.pop(); // invalid
var bar:uint8[4] = [1, 2, 3, 4];

The ability to type any variable including arrow functions.

var foo:uint8 = 0;
var foo = uint8(0); // Cast

var foo:(int32, string):string; // hold a reference to a signature of this type
var foo = (s:string, x:int32) =  s + x; // implicit return type of string
var foo = (x:uint8, y:uint8):uint16 =  x + y; // explicit return type

Function signatures with constraints.

function Foo(a:int32, b:string, c:bignum[], callback:(bool, string) = (b, s = 
'none') =  b ? s : 

Re: ES8 Proposal: Optional Static Typing

[Brandon Andrews]

 My personal feeling is that I’d rather ES not have static typing of this 
 form.  I believe it makes the language substantially more complex, and to me 
 it feels best to try to minimize the growth of the language in order to 
 ensure that those things that we do add are added in a compatible and sound 
 way.  Also, I wonder if static typing wouldn’t work out better if instead of 
 extending ES, you found a way to instead make wasm 
 (https://www.w3.org/community/webassembly/) powerful enough to handle the 
 language that you want.  The benefit of that route is that (1) there is 
 already support behind wasm and what I see as a broad desire to enable wasm 
 to handle statically-typed object-oriented/functional languages, and (2) it’s 
 a clean slate, so a proposal doesn’t have to worry about the compatibility 
 issues.



It's an understandable response. Just looking at the changes required is 
absolutely daunting in the complexity. The way I view it though is growing the 
language slowly, without types in place, is actually causing more complexity 
and limiting the language for future growth. The way TypedArrays and SIMD for 
instance were approached are needlessly verbose. Now that types are being seen 
as a requirement the way they're handled is being done poorly. The aversion to 
topics like operator overloading being the clear candidate when looking at 
SIMD. The complexity continues when looking at the syntax proposed for class 
operator overloading in the previous suggestions 
http://www.slideshare.net/BrendanEich/js-resp/15 . This is something that will 
continue as more types and features are added. Setting up a framework for types 
and language features early on will allow these features to be added with clean 
polyfills.

As much as I like the idea of WebAssembly I don't see it being viable for 
decades. In the mean-time ECMAScript will still exist and grow as a language. 
One day it'll be implemented on top of WebAssembly and personally I'd like 
Javascript to age well. It's rather close to being a very general purpose 
language. (I use it on the client, server, and database(PLV8) which is pretty 
awesome. It'll be years before WebAssembly gets to that level).


 ```js
 bignum

 float16/32/64/80/128
 decimal32/64/128
 int8x16/16x8/32x4/64x2/8x32/16x16/32x8/64x4
 uint8x16/16x8/32x4/64x2/8x32/16x16/32x8/64x4
 float32x4/64x2/32x8/64x4
 rational
 complex
 ```
 Are these types baked into the language, or can these types be user-defined?  
 It’s fine if they are user-definable but present in the standard library, but 
 it seems weird if these were baked in at the language level.

Yes, they'd be baked into the language as core types. One of the big reasons is 
that they'd be natively implemented generally by implementations. There is no 
fast way to implement bignum without a native implementation. I've written 
bignum algorithms in Javascript before and never got performance anywhere close 
to native. Same for SIMD operations, thus the SIMD proposal in ES7.

 In theory the following current keywords could be deprecated in the 
 long-term: Boolean, Number, String, Object, and the TypedArray objects. 
 Their methods and features would be rolled into the new type system.

 Deprecating these would be almost impossible given how widely used they are.  
 We still have to support JS idioms from before ES1 standardization (like 
 function.arguments).

It's something that could co-exist for years along-side the preferred ones. If 
ES8 has an implementation a warning might exist that would continue for a 
decade. A lot of web developers have kind of got used to the idea of living 
specs from HTML5 and CSS's continuous changes. It's not that the features would 
be removed, they just might not exist forever or in all implementations.


 Support for resizable typed arrays.
 ```js
 var foo:uint8[];
 foo.push(1);
 var bar:uint8[] = [1, 2, 3, 4];
 ```
 Currently, typed arrays are not resizable.  Are you suggesting that this is a 
 separate type from the existing typed array types?


Yes. A resizable typed array is a new types proposed here. What we have right 
now would be essentially a var foo:any[] = [1, 'foo', {}]; example. A resizable 
typed array, like the current type array, has finer control for allocation with 
the advantage of native implementation speed. I was talking to people comparing 
this to C++'s Vector class. If it should have things like a capacity would be 
up for debate if it's even worth it.


 Support for fixed-length typed arrays:
 ```js
 var foo:uint8[4];
 foo.push(0); // invalid
 foo.pop(); // invalid
 var bar:uint8[4] = [1, 2, 3, 4];
 ```
 How do you propose to handle:
 ```js
 var foo:uint8[4] = …;
 var bar:uint8[8] = …;
 if (p) return foo; else return bar;
 ```
 Is this a type error, or does the function have some type?  This is an 
 important question.  Usually, non-resizable arrays do not store the length as 
 part of the type, since preserving a relationship between length and type is 

Re: ES8 Proposal: Optional Static Typing

[Brandon Andrews]

 I heard Gilad Bracha in ECOOP to say [paraphrase] optional typing is great 
 to help with documentation, and to help the tools; but it should not touch 
 the runtime. This is what I take for my own as well, nicely said. Your 
 overload proposition, though, changes the language so that this would need to 
 touch the runtime. It seems there are two distinct view on bringing static 
 typing in to dynamically-typed languages: one of them in line with the 
 aformentioned, the other taking over the semantic and runtime as well. There 
 are also two terms: optional typing and gradual typing. I really don't 
 know if those are defined precisely, but there seemed to be a sentiment that 
 optional typing is the Gilad-Brachaish Strongtalk-like view, and gradual 
 typing is the view that actually changes the semantics of the language and 
 the runtime. What I wanted to say, is, that maybe this thread should be 
 called ES8 Proposal: Gradual Static Typing.


I'm definitely advocating run-time changes. Adding static typing that does 
nothing other than help with code-hinting or documentation would be pointless. 
I don't think anyone would seriously consider changing the language just for 
that. While having cleaner documentation, code-hinting, and more readable code 
would be useful a bigger change is performance. Giving programmers the ability 
to write clear code that also gives them finer control over allocation and data 
structures is key in the continued and expanding usage of Javascript. It's with 
these changes I'm hoping Javascript can be used more as a scripting language to 
further fill gaps where other languages are used. I think that's also the view 
many hold when they proposed SIMD integration. SIMD alone though is a targeted 
fix for a few applications. Types on a whole solve many small performance 
issues across numerous applications.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES8 Proposal: Optional Static Typing (Brandon Andrews)

[Ron Waldon]

 One of the first complications with types is typeof's behavior. All of
the above types would return their string conversion including bool. (In my
experience boolean is seen as verbose among C++ and C# developers.
Breaking this part of Java's influence probably wouldn't hurt to preserve
consistency for the future).

I can't see typeof changing at all. Verbose output doesn't seem like a
problem that is worth breaking backwards-compatibility to solve.

We've seen a new pattern in ES5 and continued now with ES2015:

- Array.isArray()
- Number.isNumber()
- Object.isObject()
- etc...

Perhaps this pattern just needs to be continued for all types, including
the TypedArrays (if not already being considered). I personally like this
pattern because it doesn't change typeof, and it provides an less-verbose
alternative, and it is able to be polyfilled because it's an API addition
and not a syntax change.

Other than this, I like the idea of optional static typing. I am a
little ambivalent about the syntax. I can't decide if it literally should
just be decorators, or if it deserves something more special.

Perhaps all we really need here is the ability to name decorators using
Symbols. This way, ECMA / TC39 can use real data over time to add type
decorator Symbols for the 90% case without conflicting with future code. By
virtue of being built-in Symbol-named decorators, they should still be able
to natively-optimised and statically-analysed.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES8 Proposal: Optional Static Typing

[Filip Pizlo]

Hi Brandon,

Thanks for writing this up!

My personal feeling is that I’d rather ES not have static typing of this form.  
I believe it makes the language substantially more complex, and to me it feels 
best to try to minimize the growth of the language in order to ensure that 
those things that we do add are added in a compatible and sound way.  Also, I 
wonder if static typing wouldn’t work out better if instead of extending ES, 
you found a way to instead make wasm (https://www.w3.org/community/webassembly/ 
https://www.w3.org/community/webassembly/) powerful enough to handle the 
language that you want.  The benefit of that route is that (1) there is already 
support behind wasm and what I see as a broad desire to enable wasm to handle 
statically-typed object-oriented/functional languages, and (2) it’s a clean 
slate, so a proposal doesn’t have to worry about the compatibility issues.

Personal feelings aside, I’ve got questions/comments:

 On Jul 18, 2015, at 12:35 PM, Brandon Andrews warcraftthre...@sbcglobal.net 
 wrote:
 
 ES8 Proposal: Optional Static Typing
 
 It was once said by Brendan Eich that 'Types are hard. This doesn't mean no, 
 never.' It's been a while since ES4. With ES6's TypedArrays and classes 
 finalized and ES7 SIMD getting experimental tests, ECMAScript is in a good 
 place to finally discuss types again. The demand for types as a different 
 approach to code has been so strong in the past few years that separate 
 languages have been created to deal with the perceived shortcomings. Types 
 won't be an easy discussion, nor an easy addition, since they touch a large 
 amount of the language; however, they are something that needs rigorous 
 discussion. I'm hoping this initial proposal can be a way of pushing the ball 
 forward. Turning this into an official proposal discussed by TC39 is the 
 goal. This could very well be most of ES8 due to the complexity.
 
 Since it would be potentially years before this would be implemented this 
 proposal includes a new keyword enum for enumerated types and the following 
 types:
 
 number
 bool
 string
 object
 int8/16/32/64
 uint8/16/32/64

I agree that these types are fundamental.

 bignum
 float16/32/64/80/128
 decimal32/64/128
 int8x16/16x8/32x4/64x2/8x32/16x16/32x8/64x4
 uint8x16/16x8/32x4/64x2/8x32/16x16/32x8/64x4
 float32x4/64x2/32x8/64x4
 rational
 complex

Are these types baked into the language, or can these types be user-defined?  
It’s fine if they are user-definable but present in the standard library, but 
it seems weird if these were baked in at the language level.

 any
 void
 
 These types bring ECMAScript in line or surpasses the type systems in most 
 languages. For developers it cleans up a lot of the syntax, as described 
 later, for TypedArrays, SIMD, and working with number types (floats vs signed 
 and unsigned integers). It also allows for new language features like 
 function overloading and a clean syntax for operator overloading. For 
 implementors, added types offer a way to better optimize the JIT when 
 specific types are used. For languages built on top of Javascript this allows 
 more explicit type usage and closer matching to hardware.
 
 In theory the following current keywords could be deprecated in the 
 long-term: Boolean, Number, String, Object, and the TypedArray objects. Their 
 methods and features would be rolled into the new type system.

Deprecating these would be almost impossible given how widely used they are.  
We still have to support JS idioms from before ES1 standardization (like 
function.arguments).

 
 One of the first complications with types is typeof's behavior. All of the 
 above types would return their string conversion including bool. (In my 
 experience boolean is seen as verbose among C++ and C# developers. Breaking 
 this part of Java's influence probably wouldn't hurt to preserve consistency 
 for the future).
 
 The next few parts cover type features that should be supported. The examples 
 aren't meant to be exhaustive but rather show parts of the language that 
 require new grammar and discussion.
 
 Support for nullable types.
 
 var foo:uint8? = null;
 
 Support for resizable typed arrays.
 
 var foo:uint8[];
 foo.push(1);
 var bar:uint8[] = [1, 2, 3, 4];

Currently, typed arrays are not resizable.  Are you suggesting that this is a 
separate type from the existing typed array types?

 
 Support for fixed-length typed arrays:
 
 var foo:uint8[4];
 foo.push(0); // invalid
 foo.pop(); // invalid
 var bar:uint8[4] = [1, 2, 3, 4];

How do you propose to handle:

var foo:uint8[4] = …;
var bar:uint8[8] = …;
if (p) return foo; else return bar;

Is this a type error, or does the function have some type?  This is an 
important question.  Usually, non-resizable arrays do not store the length as 
part of the type, since preserving a relationship between length and type is 
generally a hard problem.  The trivial approach - making the above be a type 
error - was done in Pascal and 

Re: Instance bound class methods

[Bergi]

Matthew Robb schrieb:

What I'd really like to have in the language is the ability to store a
property access into a single binding


Notice that the https://github.com/zenparsing/es-function-bind proposal 
does exactly this, at least for methods (and I don't think I would want 
it for arbitrary assignments). Your example code would look like this:


let someObj = { doStuff(){} };

let doStuff = ::someObj.doStuff;

doStuff();

 Bergi


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