Re: Proposal: Optional Static Typing (Part 3)
I moved some more thoughts to an issue. I'm finding this discussion is helping me a lot to see potential problems and what syntax might need to be included for everyday use. https://github.com/sirisian/ecmascript-types/issues/29 I included code to const/freeze Object also to continue the ideas presented earlier. At the bottom of the issue is my concerns and also some possible syntax proposals for essentially what other languages would call a sealed class. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Proposal: Optional Static Typing (Part 3)
Some follow-up as I think more about this.
> You can't freeze all builtins for obvious reasons.
I'm getting that the reason for not freezing them would be to define
extensions? Could they not be defined and then frozen? I get that doesn't stop
them from being dynamic still.
The ability to change the built ins like Object causes a number of issues as it
makes all classes dynamic and your destructuring swap shows that well. It seems
like as long as Object can be modified everything has to use run-time checking.
If Object could be made non-dynamic - froze it and made it const (or
equivalent) - then one could write:
```js
const f = function(a:A)
{
a.x = 0;
}
const A = new class
{
x:uint8 = 5; // Object.defineProperty(A.prototype, 'x', { type: uint8,
writable: true, value: 5 }); (I think, might have to think about this again,
been a while).
}
f(new A()); // A is dynamic and the interpreter is forced to use a run-time
check.
Object.freeze(A); // A is both const and frozen making it no longer dynamic? If
the dynamicness was removed then the engine could search the code/AST and
optimize f doing essentially a compile-time check at that point
f(new A()); // Compile-time verification for all instances of f where the
argument is typed or the type can be inferred.
```
This usage of const works at global scope, but I feel like I'm missing
something that would undermine this. Like without real namespace support this
won't work well for some libraries. The syntax is also wordy and confusing. One
could add const class A {} modifiers, but that's still confusing since
codebases would be filled with it.
Also expecting users to freeze their classes to allow the interpreter and JIT
to function sanely is asking a lot.
One problem that keeps bothering me is this delayed freezing doesn't help
tooling. A class could be created, properties added in a complex operation,
then the class frozen later. The tooling would be blind to all these changes.
I'm probably just barely touching the surface of issues. Anything I'm
overlooking?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Proposal: Optional Static Typing (Part 3)
>> Part of this has had me considering if freezing classes (and all recursively
>> referenced types) used in the type system is viable.
```js
function foo(bar: Array.)
{
// whatever
}
[Array, Set] = [Set, Array];
foo(new Array([Set()]));
```
> You can't freeze all builtins for obvious reasons.
I'm out of ideas. Do you or anyone here see a way to get around such an issue?
> You totally omitted point that your type system can't use or describe this
> function:
```js
function issue(Ctor)
{
assert(Reflect.isConstructor(Ctor)); // Type system don't provide way
to disguintish object with [[Construct]] and [[Call]] methods.
assert(Foo.isPrototypeOf(Ctor)); // Type system don't provide way to
ensure prototypal inheritance
const retClass = class extends Ctor // Type system don't provide way to
describe types being returned from function
{
};
Object.assign(retClass.prototype, mixin); // Object.assign can be
overridden to do anything, so actual code execution is required to prove it's
valid
return retClass;
}
```
Just to be clear. Is Ctor a type? Like "class Ctor extends Foo {}" or an
instance? If it's a Type it might be better handled with generics later like:
```js
function issue(mixin)
{
const retClass = class extends Ctor
{
};
Object.assign(retClass.prototype, mixin);
return retClass;
}
```
I hope I understood the requirements. Is it necessary to allow the type system
to handle passing types as arguments? Do other languages allow this?
```js
assert(Reflect.isConstructor(Ctor)); // Type system don't provide way to
disguintish object with [[Construct]] and [[Call]] methods.
```
So you'd expect a language feature like an interface that mandates a
constructor or something more general like "this object is a class"?
```js
assert(Foo.isPrototypeOf(Ctor)); // Type system don't provide way to ensure
prototypal inheritance
```
So I should explicitly state that derived classes can be passed to parameters
typed with their super like most languages allow like:
```js
class A {}
class B extends A {}
function f(a:A) {}
f(new B()); // Valid
```
In your example:
```js
function issue(Ctor:Foo):Foo
{
}
class A {}
// issue(new A()); // TypeError, A must be type Foo or extended from Foo
```
Is that sufficient?
```js
const retClass = class extends Ctor // Type system don't provide way to
describe types being returned from function
{
};
```
Would this be asking for interfaces and structural matching like in TypeScript?
I left it out originally to simplify the proposal with the expectation it would
be added in later. Do you see this more as a mandatory feature? "any" can be
used in the meantime unless I'm mistaken. (I should probably add a section in
the proposal covering this).
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Proposal: Optional Static Typing (Part 3)
> (btw the SIMD proposal has been dropped to stage 1, and implementations are > not pursuing implementing it in JS for now > tc39/proposals/blob/master/inactive-proposals.md) Yeah, that seemed predictable. I wanted the SIMD operations to use operators intuitively. That and all the SIMD core types lacked ECMAScript equivalents. Like one expected to be able to write SIMD code and not lose all the speed-up dealing with Number or casts. Was never really sold on the idea of having a float32x4 when the language can't even represent float32 without a TypedArray. Putting the cart before the horse. > where is this demand coming from? Wherever TypeScript and Flow are used; so companies like Microsoft and Facebook. I know friends that use TypeScript exclusively for application development with teams of over three people. Personally I've worked on projects over 25K lines of Javascript usually by myself, and while it would have been nice to have types it's not necessary for what I did. I didn't use classes either and relied more on a mix between agile and cowboy programming. Things have changed over the years though. One of the reasons I started wanting types and created this specification years ago was because I was working on more complex applications. Essentially taking programs that would be written (or were written in my case) in C++ and C#/WPF and writing them for the web for Android, Mac, Linux, and Windows. Part of this involved architecting and designing out ORM systems with database types and schemas. I was also doing a lot of binary WebSocket stuff at the time, some of which was somewhat performance critical with node.js on the backend. So to answer your question the demand would be developers that have transitioned to using HTML5 and Javascript for application development in teams. (In my case programs for all OSes along with web applications and interfaces). There's other reasons. My work projects have spawned off personal projects for myself in networking in databases. I'd like to use Javascript more, but I tend to fallback to C++ or C# simply because of the lack of types. I find it strange to pretend like the demand isn't there. TypeScript, and Flow have existed for a while now and I hear about them all the time in my circles. OST as described in my mind brings in the core features that people are seeking such that they can use Javascript again by itself in the future. Some people might not use them, but a lot of people would in certain places. It also might open up new features and spin-off languages since types would have already been handled without reinventing the wheel like AS3, TypeScript, and Flow did. Also realize I never intended this proposal to be implemented right away. It could take years still. Part of my slight worry as things draw on is that with all these proposals floating around that one of them will change the grammar slightly add new tokens, ASI, or other slight changes and make types infeasible or very inconsistent across the language. > Choosing type system descending from Java type system is message "creators of > language endorse OOP as main JavaScript paradigm". It's fine for TypeScript > to take opinionated approach, but it's unlikely with TC39. More like descending from Actionscript 3. I wouldn't relate a type system to OOP though. People still write non-OOP TypeScript. If you want to blame the rise of classes in Javascript you'd be looking at the introduction of classes themselves. You give programmers what they want and they'll use them for frameworks and programming. (The old way was just ugly or cumbersome so people avoided it was my experience). In any case classes are already in the spec. Types aren't going to change that. > Runtime type checking would incur significant cost on browsers (and > JavaScript parse time is already an issue for smartphone CPUs). It's > especially important to remember about dynamic nature of JavaScript. > TypeScript can rely on assumption that no one creates accessors on > Object.prototype or Array prototype, but it's unacceptable for language > feature. I'm glad you brought that up. I've been thinking about this problem of types changing for a while. Can you write down a bunch of examples and scenarios? It would help to analyze them. (Creating an issue with all of them would be ideal). Part of this has had me considering if freezing classes (and all recursively referenced types) used in the type system is viable. That is referencing a class in say a variable declaration or function signature would freeze the class. Seems a bit extreme of an option though that would cause problems for certain designs or ideas later where people want to add, remove, or update properties. Is it that important? When would a freeze even happen? I think having a lot of examples would make this easier to analyze. > People hates writing types > That's why C++ have auto, Kotlin have val, and it's
Re: Proposal: Alternative public, private, static syntax and questions
https://github.com/sirisian/ecmascript-class-member-modifiers Is this closer to what you think would be acceptable? Essentially C++/TypeScript kind of modifiers. Or does that still have issues? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Proposal: Optional Static Typing (Part 3)
> I'm still yet to read the entire proposal, but with a quick skim, it seems to > me like this is essentially what Typescript or Flow offers you: i.e. an > opt-in type system? This is in the core of ECMAScript, so the types would be real. The implementers would be encouraged to use native hardware types. But yes, outside of that it is an opt-in type system. Language built on top of it would then benefit from this. I often wonder if languages built on top of ES6 haven't limited themselves because types don't exist. That is they'd do more, but didn't because the complexity of transpiling. Stuff like this: https://github.com/Microsoft/TypeScript/issues/4639 Imagine if ECMAScript already had all those types and support function overloading. TypeScript could move on and implement more experimental ideas. > I'm wondering if you have any good reasons to want there to be a standardised > static type annotation syntax within ECMAScript instead of a "Bring Your Own > Type Checker" system. If you do have some thoughts on this, you might also > want to include that as a preface on your Github's README.You have a > "Rationale" bit that seems to ignore the existence of these existing systems. Did you read the rationale? It specifically says: > 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. More of the rationale was below the types proposed. I've moved it up into the rationale since it fits better there. If there's more you think should be added I'll include it. I'm trying to keep things concise since it's a long proposal. I could go into an explanation that TypeScript and other languages are generally just a superset of Javascript and benefit from bringing their features closer to the base language and possibly the hardware? It seems too obvious to me to write something like that. > From a quick read, I'm more in favor of something that's a little more > restricted to start, something like what Python has. Python has optional > static type annotations, but the Python interpreter just ignores them. They > are present purely for the purposes of tooling, and are silently ignored at > runtime. The goal with this proposal is to get essentially native hardware types where applicable. All the proposed types have special operator rules, value ranges (overflow behavior), and in the case of SIMD very real performance impact behind them. While documentation hints are a side-effect, I'm more focused instead for pushing ECMAScript toward being a more powerful language. Python is a classic example of where data type shortcomings lead to unintuitiveness or weird design like: https://docs.python.org/2/library/array.html I'm trying to avoid such things. > One of the reasons why I'd prefer a simpler approach to start is that > TypeScript and Flow, the two main implementations that add syntax, have a > *very* similar syntax, but have several nuances that would make a heavier > proposal much harder to accomplish: > - Flow has `?Foo` for optional types, TypeScript just uses unions. I have a section on unions with a small explanation on why I left it out. I kept it simple by only adding nullable types. Right now someone would overload or use 'any'. > - TypeScript has mapped/index types, where Flow uses special named types. I didn't include these. > - Flow allows omitted parameter names in function types, TypeScript only > allows named parameters with implicit `any` types. I created an issue to be more explicit about optional and default typed parameters and the behavior. > - Flow has exact types, TypeScript doesn't. I hadn't even considered something like this. It sounds interesting for configuration options. They introduce new tokens. Something I'm very much avoiding for this initial proposal. > - Flow has `opaque type`, TypeScript only has `type`. Something to be decided later. Doesn't create breaking changes to add later. > - Flow constrains with `T: Super`, TypeScript uses `T extends Super`. There's a section on generics and why it isn't included already. I'm with you that it's far too complex to add in with initial types. There's no breaking changes introduced by adding it later. (Mostly because it introduces new tokens which would be a huge deal). > - Flow has existential types, TypeScript doesn't. I definitely haven't included this. Flow is a few steps ahead of this proposal. It seems like a lot of these features already aren't included in the proposal. I definitely hold your view that the proposal has to be minimal, but I think my minimal is functionally minimal. Something that when implemented allows developers to experiment and then discussion can progress from there to how more features can be added. I'm trying to be thourough though as to not harm a future proposal so if any of my decisions block something I'm open to
Re: Proposal: Alternative public, private, static syntax and questions
That is a very useful document. I guess I haven't opened the proposal in a while. He puts a lot of stress on preserving encapsulation where as I was planning on relying on a type system to optionally provide that feature. That is given a dynamically typed variable accessing privates would probably be allowed. (Statically typed variables would detect and not allow that kind of like a more strict usage). I think the inheritance and using private names as keys are decent arguments. That said I'm personally not against allowing inherited classes access to their base class private members though. That is private acting like protected in C++ I think is fine for ECMAScript. Am I alone in being fine with that behavior? I'm kind of leaning toward: https://github.com/tc39/proposal-private-fields/issues/14#issuecomment-216348883 that syntax for a true private class scope variable. The key name conflict seems niche outside of key based data structures. I wrote an ORM system before and just used a key called "internal" to hold data in the past to get around a similar conflict. The # sounds like a similar workaround when required but allows everything to not be hidden in a nested object which is nice. Are "protected" class fields a thing in this discussion at all? Or is the idea to use or implement a friend system later somehow? With how I use Javascript currently, and the direction I want ECMAScript to head - toward types - I don't particularly like the proposal or necessarily support its goals toward creating an ideal encapsulation. (Also I really dislike the syntax). ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Proposal: Alternative public, private, static syntax and questions
I created a thread about static constructors a while ago here: https://esdiscuss.org/topic/proposal-for-a-static-constructor-and-static-member-variables It left me with some design thoughts so I wrote up the following proposal idea below, but never posted it because I couldn't understand why the current Stage 3 private proposal introduced a new token '#'. Maybe I missed something obvious in the design of the grammar or the way the internals work, but I didn't understand. Also I didn't understand why it does this.#x which seems verbose since every language with private members doesn't introduce this clutter. (It's like writing private everywhere you use it rather than one place which can't really be the simplest implementation right?). https://github.com/sirisian/ecmascript-public-private-static In the above proposal above I stuck with 'private' and 'static' keywords since it seems closer to other languages. Also I kept with the idea that default behavior is public to not introduce breaking changes. Can someone explain why ECMAScript can't use something like I proposed? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Proposal: Optional Static Typing (Part 3)
It's been a year and a half since my last post and I've made a number of small changes and corrections over 2.5 years. The proposal is still on my github at: https://github.com/sirisian/ecmascript-types I've talked to a lot of people about it, but I haven't gotten much criticism or suggested improvements. I'm a bit in over my head in trying to flesh out all the details or all the nuanced syntax changes that a championed proposal would be expected to do. That said I've been making more changes lately to try to find edge cases and potential problems. I've been jotting down issues here: https://github.com/sirisian/ecmascript-types/issues I closed a number of them recently as I made changes. If anyone has any comments on what I should expand, look into more, or change I'm open to discussing them here or on github. One issue in particular is this: https://github.com/sirisian/ecmascript-types/issues/15 It covers whether I should introduce a new assignment operator to my proposal. Maybe there's another way to look at it or a different solution. I need fresh eyes on the whole proposal really to get a list of new issues to tackle this year. I'm also not against having one or multiple people champion it and working on it without me. (I haven't been able to dedicate time to read the ECMAScript spec and really understanding the grammar fully so having someone qualified to take over would help the proposal a lot). Thanks for reading the proposal for anyone that has the time. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Migrating to a better communication tool
Previous discussion: https://esdiscuss.org/topic/meta-proposal-switch-es-discuss-from-a-mailing-list-to-using-the-tc39-github-issue-tracker-for-discussion I argued there for using Github issues in the TC39 account and covered every concern brought up. I'll point out it's trivial to use github's API to convert all of the mailing list into individual issues. Also I've noticed people don't know how mailing lists work. (This should be obvious glancing at any topic brought up). I regularly still get people sending me emails and they don't CC things correctly. If I would hazard a guess there has been hundreds of lost comments from people replying to the mailing list wrong. That said TC39 would have to decide on this among themselves and they seem indifferent. There's also a common theme among mailing list communities that it keeps the low-effort comments out compared to Github, Discourse, and numerous other platforms. If it wasn't for esdiscuss.org to view these mailing list I'm not sure I'd even follow these discussions myself. I find it hilarious that using google and searching site:esdiscuss.org is the easiest way to find old threads though. No wonder this thread was made. OP probably couldn't find all the old discussions. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Proposal for a static constructor and static member variables
The public one is the one I was thinking of when I said it shouldn't conflict.
(I don't see the private spec going anywhere to be honest with that syntax, but
if it does that would be interesting).
As for the conversion, yes that would be a good conversion for the first
example. In the second example putting things outside places them in a
different scope. Imagine you had multiple classes defined and they had their
own instances member.
As for static constructors a more contrived example would be a memoization
operation where one does initial work or generation in the static constructor
rather than initialization.
```
class MathLibrary
{
static table = {};
static constructor()
{
// Common cases
for (let i = 0; i < 100; ++i)
{
MathLibrary.table[x] = // something complex and time consuming
}
}
static Calculate(x)
{
if (MathLibrary.table.hasOwnProperty(x))
{
return MathLibrary.table[x];
}
else
{
let complexCalculation = // something complex and time consuming
MathLibrary.table[x] = complexCalculation;
return complexCalculation;
}
}
}
```
> Keep in mind that if something is a "static" in the ES6 class method sense,
> you will never be able to do `this.instances` to get it because the property
> does not live on `this`, it lives on the constructor.
I'll have to think about that. Might need another proposal. I always like to
think about static methods and variables as being shared among all instances.
Would be nice to get that kind of meaning also. Essentially aliases. Accessing
static methods inside of a instance methods requires using the type name which
I find less than ideal. Probably a personal preference though.
On Wednesday, January 25, 2017 11:41 PM, Logan Smyth
<loganfsm...@gmail.com> wrote:
So we're on the same page, in the active proposal list
(https://github.com/tc39/proposals) you'll find* Public Fields:
https://tc39.github.io/proposal-class-public-fields/* Private Fields:
https://github.com/tc39/proposal-private-fields
Public Fields includes a syntax for static properties that would convert your
example to something like
```class Multiton { static instances = {};
constructor(name) {
if (Multiton.instances.hasOwnProperty(name)) throw `Multiton name
already used`;
Multiton.instances[name] = this;
}
}
```
though I don't know I'd personally do this in this instance, rather than
putting it outside the class, like
```
const instances = {};class Multiton { constructor(name) {
if (instances.hasOwnProperty(name)) throw `Multiton name already used`;
instances[name] = this;
}
}
```
Keep in mind that if something is a "static" in the ES6 class method sense, you
will never be able to do `this.instances` to get it because the property does
not live on `this`, it lives on the constructor. I'm unsure if the private
fields proposal would allow `static #instance = {};` as a static with
`#instance[name] = this;` inside the constructor.
On Wed, Jan 25, 2017 at 8:40 PM, Brandon Andrews
<warcraftthre...@sbcglobal.net> wrote:
The initial proposal for discussion is below:
https://github.com/sirisian/ ecmascript-static-constructor
I don't believe this conflicts with other proposals yet, nor any future
proposals. Essentially it adds static members in a very compact syntax with
minimal grammar changes required.
What I foresee happening years from now is public, private, and static member
syntax will be added. Much like how public members are defined in the
constructor for the moment the static constructor would be the way to define
static members of the class for now.
Thoughts?
__ _
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
Proposal for a static constructor and static member variables
The initial proposal for discussion is below: https://github.com/sirisian/ecmascript-static-constructor I don't believe this conflicts with other proposals yet, nor any future proposals. Essentially it adds static members in a very compact syntax with minimal grammar changes required. What I foresee happening years from now is public, private, and static member syntax will be added. Much like how public members are defined in the constructor for the moment the static constructor would be the way to define static members of the class for now. Thoughts? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Optional Static Typing (Part 2)
> - Changing behavior of typeof would probably break the web or cause big
> troubles (eg. "we can't upgrade library because new objects break our typeof
> checks").
That's why all breaking changes are behind the "use stricter" mode. In the
normal mode typeof functions as one would expect with the normal rules. I've
separated "use stricter" into another proposal to avoid confusion and keep
things independent.
> - Including special types like "uint32" is MUCH bigger task than including
> optional typing - we need to get types first, then include compile time type
> checks
Agreed, I noticed 64 bit integer operations are already in discussion at stage
0: https://github.com/tc39/proposals/blob/master/stage-0-proposals.md I assume
you mean I need to expand the sections 6.1 in my spec changes and detail every
type. It's on my list of things to work on. Or are you suggesting another path
toward types with a more minimal proposal first?
> - Typed exceptions are inferior to more flexible exception filters
One of my friends brought this to my attention already. Maybe I'm missing a big
picture thing, but could we not have both? Would introducing typed exceptions
block the introduction of exception filters? One of the things I've been
looking at are future proposal conflicts so this would be a very interesting
one to analyze. If it does conflict I can remove it and add a note in the
future concerns section that another proposal will need to make those changes.
> - Your type system is primitive - it's support for functions is almost
> non-existant (what is your type annotation for foo:uint32 => bar:float32 =>
> anno:string => `${anno} = ${foo+bar}), unions, intersection types, this type,
> interfaces.
let baz:(uint32):(float32):(string):string = foo:uint32 => bar:float32 =>
anno:string => `${anno} = ${foo+bar}`;
I have function signatures in the proposal already. Maybe I need to expand the
examples though. Would it be possible for you to create issues with examples
for the ones you listed and what you'd expect the type annotations to be for
each. There's still an open issue that has some complex examples:
https://github.com/sirisian/ecmascript-types/issues/2 Someone else was debating
the merits of different syntax in that issue.
Also while it might seem primitive the proposal is designed so that it could be
expanded later. If you have concerns regarding how it might conflict with more
complex type system features in the future I'd be very interested in that. I
have a section on generics since people kept bringing it to my attention.
Ideally this proposal is somewhat minimal as a first step into types. I fear
that if I include anything outside of a minimally viable type system it would
be immediately rejected. Presenting the core foundation for a type system with
clear paths towards other type system features I think is much easier for the
community and implementors to work with.
> - "use stricter" - it's out of scope of optional static typing
You're right. I've spun it off into its own proposal.
https://github.com/sirisian/ecmascript-use-stricter Can work on that after
things are done then and ensure things work independently from any semantic
changes. It was created initially because of feedback I got that people wanted
to see type annotations as strings and that typeof could be repurposed to be
more useful. Needs a lot more thought. So does instanceof for that matter.
> - Multiple dispatch in dynamic language is much bigger problem than one
> section paragraph.
Agreed. Every section relating to it needs to be expanded a lot. Need to find
people that are well versed in the subject.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Optional Static Typing (Part 2)
I've been very slowly expanding a proposal that I started 1 year ago. The current proposal and links to the previous discussion is here: https://github.com/sirisian/ecmascript-types (If the link gets truncated by esdiscuss.org because of the hyphen view the source to see it). Since a year ago I've read through the current specification partially analyzing key pieces that would need to be modified, have their wording changed, or that would need to be discussed for static typing to happen. In that effort I've spoken to a lot of developers about certain features, preferences, use cases, and where others want the language to head. I'd rather not see this post devolve into discussions about how TypeScript, CoffeeScript, or WebAssembly exist. I've seen many people try to discuss those as reasons to not evolve ECMAScript, but as has been mentioned before the language is expected to continue to exist and evolve separate from them. What I would like from the ECMAScript community is anyone that wants to discuss specification issues or expansions to the current proposal. Basically the current pool of people I've been talking to think I've covered the key pieces they wanted to see. If anyone here is interested in the subject and wants to create issues on the github or pull requests to expand sections I'd appreciate it. I'm also looking for anyone that has more intimate knowledge about the grammar. I've been working my way through the grammar, but it's a very daunting and time consuming task for me to create the extra grammar rules or analyze conflicts. Anyone that's done that in the past and would be willing to help it would help the proposal a lot. Also since I've been asked before, when all the specification sections and grammar are done I'll look for a champion. It's too risky to present a type proposal without first considering everything which is why the proposal needs feedback and work. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Tracking proposals should be standardized with issues
For those not aware of the "currently compiled list" he's referring to this https://github.com/tc39/ecma262 It has no clear history other than viewing the change log. I agree. Ideally every link on that page should link to an issue that tracks the information. This would allow for much cleaner archival of proposals. People just need to be clear that each proposal issue is for status purposes only. The issue for each proposal could contain a link to the proposal's github repo where the mailing list and issues could be found. > It would also be worthwhile to organize more general design ideas into issues > that could be referenced by specific proposals. The thinking right now seems to be that people creating proposals should reference mailing list discussions directly. Creating issues would just mean people would be referencing an issue which then references mailing list threads. I do see the the usefulness though. Currently there are probably over 10 threads for null coalescing operators under multiple names. The mailing list has no method for marking duplicates so the posts generally just reference each other. I posted about this months ago, but I don't think there's any interest in simplifying this. In theory under the current system you should create a proposal then get it to stage 0 then everyone would reference the proposal which would then reference the full list of discussions. That is general design ideas really just need a stage 0 proposal. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Re: New Assignment Operators (Not bit-wise OR)
Perhaps this proposal might fit with what you had in mind: https://esdiscuss.org/topic/proposal-for-a-null-coalescing-operator Been meaning to clean this up and submit it as an actual proposal since the idea is kind of simple: https://github.com/sirisian/ecmascript-null-coalescing-operator ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Are there any 64-bit number proposals under consideration?
You can view the current proposals here: https://github.com/tc39/ecma262 There are none that mention 64-bit types. The closest might be the "Typed Objects" proposal. I started a competing type proposal (still in the theory stages) here https://github.com/sirisian/ecmascript-types in an effort to define types into the core language. (Compared to adding ad-hoc objects for every proposed type). Something like that would take years progress through the proposal system though. (Been too busy to finalize it and present it for stage 0). Right now the lack of 64-bit integer types is also holding back the TypedArray stuff from supporting them. There was also this post from 4 years ago: https://esdiscuss.org/topic/value-objects Not much progress on any fronts though from what I've seen. From reading a lot of the mailing list casually there were quite a few users against adding more types or extending the language with types in the past. Not sure if they're still here though. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Proposal for a null coalescing operator
https://en.wikipedia.org/wiki/Null_coalescing_operator Essentially x ?? y will return x when not null or undefined else it will return y. A nice Javascript explanation of the current problems with using || that can cause unforeseen bugs: http://stackoverflow.com/a/476445 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES8 Proposal: Optional Static Typing
Since I can't edit the original post I moved everything over to a github repo. It's easier to read the proposal there. https://github.com/sirisian/ecmascript-types Added bool SIMD types to the proposal and explained the operators more. Lot of edge cases to still define though, but it's looking rather solid. I've shown it to others that are used to TypeScript and they seem to agree with the general syntax. Still have to think more about generic constraints and typedefs/aliases/interfaces though and how they fit into Javascript moving forward. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Re: [Meta] Proposal: Switch es-discuss from a mailing list to using the TC39 GitHub issue tracker for discussion.
Personal note: If you must kill es-discuss and move it, move it to medium that is not political, that is, not to github. Github has recently made a move that pushes me to leave it as soon as I find suitable alternative. The recent changes with the open code of conduct shouldn't affect ECMAScript. For those unfamiliar the announcement was here: https://github.com/blog/2039-adopting-the-open-code-of-conduct Specifically this page: http://todogroup.org/opencodeofconduct/ I checked quickly and this doesn't appear to be incompatible with anything ECMAScript currently does or participates in. It shouldn't be that everything is in github, because github will then have too much power, and it is unable to resist the urge to abuse it. While an important topic to consider, GitHub presently has no such bent. If it does become an issue nothing stops ECMA from moving discussions someplace else. That said, the argument for centralizing keeps all the discussion and hosting in one place. This works well also since many of the community's transpilers, polyfills, and other work already exists on GitHub. In the similar vein, you cannot automatically assume everyone has / can create account on github. There is no assumption being made. Currently every country with access to the Internet can create a GitHub account. It's as easy as creating an email account. I verified this before posting. I think that might be why TC39 already uses it for a lot of their hosting. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
[Meta] Proposal: Switch es-discuss from a mailing list to using the TC39 GitHub issue tracker for discussion.
I was looking at the most recent notes. https://esdiscuss.org/notes/2015-05-27 One thing stuck out to me is that ECMA uses GitHub a lot. There was a line that caught my attention: ?: What needs to live on the ECMA GitHub? Waldemar Horwat/Allen Wirfs-Brock: Any contributions need to be in some format that ECMA can archive, for legal, librarian, and historical needs — imagine someone needing to track down the history of some contributions 15 years from now. For individual documents (pdfs, etc.) the simplest way is to send them via the ECMA reflector. ECMA keeps an archive of those forever. For ongoing things use an ECMA-sanctioned repository such as ECMA's GitHub. The line ECMA-sanctioned repository such as ECMA's GitHub makes it sound like GitHub is relatively trusted as an archival system. I know many people here probably love mailing lists, but I've never much cared for them. They're often riddled with mistakes and formatting errors that can never really be fixed. People also reply wrong for instance fragmenting discussions. This can hurt discussion. Also some people have problems replying to them or simply don't feel comfortable using them. I've pointed people here to view and gotten replies like I don't have time to use a mailing list. The https://esdiscuss.org/ page I think helps, but it has its own issues. Most people don't know it uses the GitHub styling so it garbles a lot of things from its plaintext version. Also, as I figured out finally, only moderators can edit their own posts which means editing to try to clean things up is impossible. So my proposal is for TC39 to create an esdiscuss project at https://github.com/tc39. So people would just go to https://github.com/tc39/esdiscuss. Then using their GitHub account they could easily login and post issues and comments without having to subscribe or figure out how to use mailing lists with their email client. GitHub's issue tracker offers many nice features also that mailing lists lack. You can have labels which is amazing for archiving. It's also very easy to search. Users can also edit their posts and past code examples trivially into their comments so comments and replies flow smoothly. As an example look at https://github.com/dotnet/roslyn/labels/Area-Language%20Design. That's a link to all the language design proposals and discussions for Roslyn. Also from what I can tell there's no country that currently blocks GitHub. At one point Russia, China, and India blocked the site, but from what I'm reading they no longer block it. In the future that might not always be the case. That's the biggest downside I can think of that would be a potential issue. I see using GitHub's issue tracker as a way of encouraging more discussion also. Pretty much every Javascript developer has a GitHub account for working with various Node.JS projects so they'd probably be more receptive following and joining in on the discussion. GitHub also has a very easy to use moderation system so it's easy to correct small formatting errors and titles to make searching simple and terminology consistent. It's also easy to see which topics are active and which are done being discussed. Is there any support for something like this? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES8 Proposal: Optional Static Typing
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
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
ES8 Proposal: Optional Static Typing
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 : ''):int32 { }
Simplified binary shifts for integers:
var a:int8 = -128;
a 1; // -64, sign extension
var b:uint8 = 128;
b 1; // 64, no sign extension as would be expected with an unsigned type
Destructing assignment casting:
[a:uint32, b:float32] = Foo();
Function overloading:
function Foo(x:int32[]) { return int32; }
function Foo(s:string[]) { return string; }
Foo([test]); // string
Constructor overloading:
// 4 byte object
value class MyType
{
x:float32; // Able to define members outside of the constructor
constructor(x:float32)
{
this.x = x;
}
constructor(y:uint32)
{
this.x = float32(y) * 2;
}
}
Number would convert implicitly with precedence given to decimal,
float128/80/64/32/16, uint64/32/16/8, int64/32/16/8. (Or whichever order makes
the most sense). As an example using the MyType class:
var t:MyType = 1; // float32 constructor call
var t:MyType = uint32(1); // uint32 constructor called
Implicit constructors could also be added to the proposed SIMD classes to go
from a scalar to a vector.
var v:float32x4 = 1; // Equivalent to an ES7 SIMD splat, so var v =
float32x4(1, 1, 1, 1);
Implicit array conversion would also exist:
var t:MyType[] = [1, 2, 3, uint32(1)];
Types would function exactly like you'd expect with decorators in ES7, but with
the addition that they can be overloaded:
function AlwaysReturnValue(value:uint32)
{
return function (target, name, descriptor)
{
descriptor.get = () = value;
return descriptor;
}
}
function AlwaysReturnValue(value:float32) { /* ... */ }
Class example and operator overloading:
class Vector2d
{
x: float32;
Re: Re: Proposal for new floating point and integer data types
Took a break while I worked on some Javascript projects for the past year to
see if they'd give me more perspective on types. I'll keep this short though.
Brendan Eich wrote:
No one is proposing type annotations a la ES4 or TypeScript, note well.
I'm thinking the discussion needs to start up again for the sake of JS's
future. Basically building a base for other languages and also making JS a more
complete language by itself. Before I get into that though I have a few
comments and questions.
Starting with this video from Brendan Eich that was linked:
https://www.youtube.com/watch?v=IXIkTrq3Rgg
Regarding Literal Syntax ( http://www.slideshare.net/BrendanEich/js-resp/14 )
used in other languages I think Javascript could handle it cleaner without
arbitrary suffixes like L, UL, f, n, and m. I'm not totally against the idea,
but would constructors always work as an alternative? bignum(1234567890). If so
it seems fine. (I just want to make sure the literal syntax is optional for all
proposed types).
The proposed operator overloading syntax (
http://www.slideshare.net/BrendanEich/js-resp/15 ) has the right idea, but I
think partial classes might be a cleaner approach. Basically being able to
define the same class multiple times and having their implementations merged
ignoring duplicates.
value class vector2d
{
x: float32;
y: float32;
get Length():float32
{
return Math.sqrt(x * x + y * y); // uses Math.sqrt(v:float32):float32
due to input and return type
}
constructor(x:float32 = 0, y:float32 = 0)
{
this.x = x;
this.y = y;
}
operator +(v:vector2d)
{
return vector2d(this.x + v.x, this.y + v.y); // return value type
}
operator ==(v:vector2d)
{
// equality check between this and v
}
}
// In MyClass.js defined extensions to vector2d
class vector2d
{
operator ==(v:MyClass)
{
// equality check between this and MyClass
}
}
The implementation would then just need to update the current class definition
as Javascript files are loaded. The other advantage with this is it allows for
organization of operators which can be convenient for math objects that are
required to work with many objects or third party code.
For value type classes are they always passed by reference? I didn't see
anything regarding pass by reference syntax. Do value classes have a copy
constructor or something for cloning objects in that case?
Okay onto typing. Ultimately what I'd like to happen is for an ECMA member to
understand the value of static typing for JS and help turn this into a rough
draft proposal that can be expanded on with critiques.
What I keep seeing from years of conversation are comments like in this thread:
https://esdiscuss.org/topic/optional-argument-types
Brendan Eich wrote:
Types are hard. This doesn't mean no, never. But big brains are still
researching the general topic, and btw what Dart has can't be called types
according to the researchers and literature I trust.
There's not even a proposal for people to begin discussing the grammar and
implications on JS though. It was given mild interest years ago, but it's past
the time for putting off the discussion. (Also it doesn't look like anyone is
against adding this. I've read a large part of the mailing list so far which
discusses typing a lot).
So what a static typing proposal should have at the minimal are the following
types (lowercase seems to look best I think):
bool
string
uint8/16/32/64
int8/16/32/64
float32/64
bignum
decimal
int32x4, int32x8
uint32x4, uint32x8
float32x4, float32x8
I saw the following mentioned in Brendan's slides and they'd probably be nice
if a standardized interface and implementation is found:
rational
complex
The ability to type any variable including lambdas. I'd go with the already
proposed syntax that's been around for years. I've read the old guard and
trademarks type proposals, but they seem unneeded for now.
var foo:uint8 = 0;
var foo = uint8(0); // cast
var foo:(int32, string):string; // hold 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
Support for typed arrays.
var foo:uint8[] = [1, 2, 3, 4];
Support for nullable types.
var foo:uint8? = null;
Function signatures with constraints.
function Foo(a:int32, b:string, c:bignum[], callback:(string, bool)):int32 { }
Function overloading:
function Foo(x:int32[]) { return int32; }
function Foo(s:string[]) { return string; }
Foo([test]); // string
So by default Number would convert implicitly with precedence given to decimal,
float64, float32, uint64/32/16/8, int64/32/16/8. (Or whichever order makes the
most sense).
Then lastly, support within the currently proposed class syntax to support
multiple constructors and fixed size classes.
// 4 byte object
value class myType
{
x:float32;
Re: Re: Proposal for new floating point and integer data types
float16/80 decimal32/64/128 Those are reasonable additions also. Wasn't sure with decimal was going to assume 128 bit for financial type applications. Having it vary with 32, 64, and 128 bit thought is much closer to the other suggestions. (I updated my original post on esdiscuss to include them.) I saw your esdiscuss post on Float16Array also. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Using const to remove debug code? Is there something stopping implementers from doing this?
Lately I've been writing very processor heavy Javascript. I feel like it could
benefit a lot from having a syntax feature for removing debug statements.
Obviously JS is interpreted and not compiled, so I'm not sure if this sounds
completely unrealistic, but it has some very useful scenarios.
I like to write verbose type checking for functions to check ranges and throw
exceptions if invalid input is detected. The issue is in a production
environment (especially with games) the code executes too slowly with all the
extra branches. It would be nice if there was a simple syntax to treat code as
if it's commented out when a flag is set. In some languages this is done with
preprocessor statements like:
#if debug
console.log(Debug Mode);
#else
console.log(Release Mode);
#endif
The alternative is simply:
const debug = false;
if (debug)
{
// Tons of type checking
}
What I'd expect would be possible for an implementer is to get to the constant
and evaluate the branch and remove the whole statement before running it
through the JIT. This would allow a very standard way to turn on and off pieces
of code. An example program:
// Debug Off Control
{
console.time(benchmark control);
for (var i = 0; i 1000; ++i)
{
}
console.timeEnd(benchmark control);
}
// Debug Off
{
const debugOff = false;
var debugOffCounter = 0;
console.time(benchmark debug off);
for (var i = 0; i 1000; ++i)
{
if (debugOff)
{
debugOffCounter++;
}
}
console.timeEnd(benchmark debug off);
}
// Debug On
{
const debugOn = true;
var debugOnCounter = 0;
console.time(benchmark debug on);
for (var i = 0; i 1000; ++i)
{
if (debugOn)
{
debugOnCounter++;
}
}
console.timeEnd(benchmark debug on);
}
http://jsfiddle.net/9LCra/
On the latest Firefox there's a 11 ms difference between the control and using
a constant in the if. In chrome there's a 23 ms difference. Is there anything
stopping an implementer from evaluating the constant and making the control and
debug off identical in performance?
I kind of want this to be like a standard goto technique that's expected to
work since I believe right now the alternative is to simply create two files or
remove anything that might slow things down.
I decided to post here first in case there's a fundamental reason that such a
use case would be impossible or if an alternative was in the works that would
fit this goal.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
RE: Proposal for new floating point and integer data types
On Sun, 10/27/13, Domenic Denicola dome...@domenicdenicola.com wrote: Subject: RE: Proposal for new floating point and integer data types To: Rick Waldron waldron.r...@gmail.com, Brandon Andrews warcraftthre...@sbcglobal.net Cc: es-discuss@mozilla.org es-discuss@mozilla.org Date: Sunday, October 27, 2013, 12:18 AM Also http://www.slideshare.net/BrendanEich/js-resp/5, presented in convenient video form at http://www.youtube.com/watch?v=IXIkTrq3Rgg. (I'm not sure how to replay to these. I see people bottom posting usually. Not overly familiar with mailing lists, so I hope this works). Woah, I didn't see that video when I was searching. (Finding a bunch searching for ECMAscript 7 and 8 and simd now). That's exactly the direction I was hoping JS would go. I was actually typing up SIMD types, but removed it as it seemed too much to request. If they're willing to add all the types and the operators with swizzling support that would probably make JS nearly perfect for computing. (I have a few projects I did in the past which could have used it). I found a gist where someone wrote of a proposal apparently https://gist.github.com/jensnockert/7a0f6a99a0f3bde2facb , looks very well thought out, even including prefetch operations which would be amazing. Looking at his direction and slides, then single and double in my proposal would be float32, float64 which is more aesthetically similar to the other types. I'm impressed at how well thought out everything is for the future of JS. I see the slide with the types he's suggesting. Are there types for the int8/16/32, and uint8/16/32? var foo = 0: float32; On slide 14 he has float32(0) indicating something like the following (or using the literal syntax): var foo = float32(42); I was worried about suggesting something like that for compatibility with old code, but if that's the direction and has no issues, then it's perfect. I just realized that Brendan Eich created JS so I assume he fully knows about any compatability issues. His solution is cleaner for conversions. With what he's proposing how do you perform a bitwise conversion from uint64 to a float64? I think the norm right now is to use the typed array spec with views for 32-bit conversions. (It comes up in a few problems). I assume they're adding Uint64Array and Int64Array with his proposed changes which would provide a solution for the bitwise conversion. I think strong typing would be a really good idea with all of these types flying around. Found a few posts Brendan Eich made about strong typing. Can't figure out how he feels about that. Would static typing ever work for JS? Kind of like a use static; with proper all or nothing compilation? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Proposal for new floating point and integer data types
I've seen posts asking for optional strong typing (often relating to
typescript), but not many asking for data types. I think since the process
takes a while it would be a good idea to consider adding extra data types on
top of the already existing dynamic ones. I'll keep each comment short since
everyone here is probably familiar with how Actionscript did their type specs.
I'd like to discuss proposing these data types to start:
int,int8/16/32/64
uint,uint8/16/32/64
single (32-bit IEEE 754)
double (64-bit IEEE 754 as an alias for Number)
These correspond to most computer hardware and have fairly standard instruction
set operations on them. The goal here is mostly to bring ECMAScript closer to a
generic bit based computer. These types are fairly standard across hardware and
are well understood in other languages.
var foo: uint16 = 100;
var bar: uint64 = foo;
var baz = bar 58;
This would in turn expand things that JavaScript was never able to do, which is
to work with 64-bit types. (The idea being this could be expanded later for
higher bit types).
This would translate to functions:
function Foo(a: int32, b: int32): int32
{
return a + b;
}
var foo = new function(): void { }
Then expanding more, users would be allowed to type functions making function
parameters easy to understand:
function Foo(a: function(a: int32, b: int32): int32): void
{
}
Other type specifications allowed would be bool, string, and object with the
concept that classes would fit seamlessly into the typing when added later.
Some specific rules would be applied. Integer data types would not throw
exceptions when overflowing keeping them simple. Any binary operation would
immediately convert a single and double type to corresponding uint32 and uint64
data types.
The untyped Number data type would convert to any of the other types if
possible. It would be up to the programmer to ensure a Number variable fits
into the required data type.
var foo = 1000;
var bar: uint8 = foo; // 232
However a programmer could explicitly convert the type with the following
syntax:
var foo = (10 * 100): uint8;
This proposal would also include changes to Array, Map, and Set with a generic
type syntax found in C#:
var foo = new Arrayint8(100); // Identical to Int8Array
var foo = new Arraystring, int8();
var foo = new Mapint32,object();
var foo = new Setobject();
It would work as one would expect only accepting a specifically defined type.
int and uint would correspond to big integer data types which would remove any
current limitation with integer based math. they would support syntax for typed
array like views.
var foo: uint = 9;
var bar: Arrayuint8 = foo;
var baz: uint8 = bar[0];
These views would also work with the non-big integer types. So:
var foo: uint32 = 42;
var bar: Arrayuint16 = foo;
var baz: uint16 = foo[0];
They would also be the only way to go from an uint32/64 and int32/64 to a
single or double like:
var foo: uint32 = 42;
var bar: single = (foo: Arraysingle)[0];
While more verbose than other possible proposals it keeps with one syntax for
all bitwise conversions.
The last edge case I'd like to cover is making the changes work with Math:
var foo: uint32 = 42;
var bar: single = Math.cos((foo * 42):double);
By default the return type would be inferred by the input type or storage type
(in this case single) and the function would be overloaded for different
inputs. As another example Math.min and Math.max would return their input data
type rather than Number when the types are specified.
Benefits to this proposal would be easier optimization to map to hardware and
operators. It would also help to alleviate the issues that caused the need for
the TypeArray spec. That is allowing the user to work with types that map to
native hardware on the CPU and GPU.
For developers who work with binary formats this simplifies the usage of
integer and floats along with their respective binary operators.
The main issue I see is that big integers are niche so it might be a bit naive
to include them, but it's something I'd prefer was included as it makes the
language flexible for the future. The other issue is defining any type of
generic syntax using would need serious discussion if there are any issues
making the system compatible.
Future additions this would allow would be function overloading, but I left
that out as it complicates the proposal.
I've been looking through the archive for similar discussions as I assume
something like this has been proposed before. If anyone has any related links
that would be appreciated along with a discussion of issues or compatibility
conflicts. (Or general feelings toward adding types in general as ECMAscript
has been fairly unchanged over the years with regards to types).
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
