domenic at domenicdenicola.com (2013-11-03T22:00:46.982Z)
I apologize for jumping in here with an incomplete understanding what's being proposed, but perhaps somebody can help clarify it for me. I've been following value types and operator overloading discussion with great interest. From the slides and video, it appears that operator overloading is only being discussed in the context of immutable value objects. Is this right? Or is it just what the examples use? If operator overloading only applies to value objects, what's the motivation? I've implemented a large part of MATLAB/R like functionality in JavaScript. The biggest hurdle is a tolerable API for the core matrix and dataframe types. While perhaps silly, it's a deal breaker for some people coming from other environments. Otherwise, JS is an amazing platform, particularly with ES6 features. A secondary issue, and probably a bigger can of worms, is whether the proposal will allow for additional operators. For matrices, there is a well-defined and established set of operators that operate elementwise and objectwise (MATLABs dot-operators vs. operators). The API Function.defineOperator(symbol, type1, type2) would be perfect to support this. However I assume this is not the intention? Is there any openness to supporting user defined infix operators or at least an extended set similar to Python's PEP 225 proposal (http://www.python.org/dev/peps/pep-0225/)? Sorry if my comments are based on not understanding the proposal.
I apologize for jumping in here with an incomplete understanding what's being proposed, but perhaps somebody can help clarify it for me. I've been following value types and operator overloading discussion with great interest. From the slides and video, it appears that operator overloading is only being discussed in the context of immutable value objects. Is this right? Or is it just what the examples use? If operator overloading only applies to value objects, what's the motivation? I've implemented a large part of MATLAB/R like functionality in JavaScript. The biggest hurdle is a tolerable API for the core matrix and dataframe types. While perhaps silly, it's a deal breaker for some people coming from other environments. Otherwise, JS is an amazing platform, particularly with ES6 features. A secondary issue, and probably a bigger can of worms, is whether the proposal will allow for additional operators. For matrices, there is a well-defined and established set of operators that operate elementwise and objectwise (MATLABs dot-operators vs. operators). The API Function.defineOperator(symbol, type1, type2) would be perfect to support this. However I assume this is not the intention? Is there any openness to supporting user defined infix operators or at least an extended set similar to Python's PEP 225 proposal (http://www.python.org/dev/peps/pep-0225/)? Sorry if my comments are based on not understanding the proposal. Tristan On Sun, Oct 27, 2013 at 7:57 AM, Brendan Eich <brendan at mozilla.com> wrote: > Brandon Andrews <mailto:warcraftthreeft@**sbcglobal.net<warcraftthreeft at sbcglobal.net> >> > >> October 27, 2013 5:45 AM >> >> ------------------------------**-------------- >> On Sun, 10/27/13, Domenic Denicola <domenic at domenicdenicola.com> wrote: >> >> Subject: RE: Proposal for new floating point and integer data types >> To: "Rick Waldron" <waldron.rick at gmail.com>, "Brandon Andrews" < >> warcraftthreeft at sbcglobal.net**> >> Cc: "es-discuss at mozilla.org" <es-discuss at mozilla.org> >> Date: Sunday, October 27, 2013, 12:18 AM >> >> Also >> http://www.slideshare.net/**BrendanEich/js-resp/5<http://www.slideshare.net/BrendanEich/js-resp/5> >> , >> presented in convenient video form at >> http://www.youtube.com/watch?**v=IXIkTrq3Rgg<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). >> > > USENET norm applies (bottom posting, AKA top-citing -- and gmail will > trick people into not trimming their citations, but please do). > > > 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<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. >> > > http://wiki.ecmascript.org/**doku.php?id=strawman:value_**objects<http://wiki.ecmascript.org/doku.php?id=strawman:value_objects>is the place where I will be editing ES7 value objects (shortly; in time > for the November meeting, I hope). Please excuse the out-of-date material. > > John McCutchan's SIMD polyfill, as my slides showed, is at > https://github.com/**johnmccutchan/ecmascript_simd<https://github.com/johnmccutchan/ecmascript_simd>. > Emscripten now has a branch targeting SIMD intrinsics. Here's what Alon > wrote recently: > > """ > I've implemented some SIMD support in emscripten, in a branch called > 'simd'. Status is: > > 1. There is a SIMD header, system/include/emscripten/**vector.h, which > defines float32x4 and uint32x4. They can be used for basic vector > operations - load/store, add/subtract/multiple/divide - which LLVM > translates into the proper LLVM vector instructions. > 2. Emscripten translates LLVM vector instructions into SIMD JS API calls, > compatible with the polyfill. > 3. Currently some basic tests work, both using the explicit vector types > from that new header, and LLVM's autovectorization (which generates the > same LLVM vector instructions). (Supporting the vector types in emscripten > turned out to be easier than I had anticipated, at least for basic usage.) > 4. This does not relate to asm.js yet, I am not sure what the status of > SIMD in the type system there is. But for smaller benchmarks that should > not prevent us from measuring useful numbers. > 5. The emscripten branch does not include the SIMD polyfill code yet (just > waiting on a license for me to be able to merge it into emscripten), so the > tests don't run out of the box yet, but you can just paste the polyfill at > the top of the emscripten output and it should work. (To run the tests, do > EM_SAVE_DIR=1 ./tests/runner.py other.test_simd or the same with > simd2 at the end, output file will be in /tmp/emscripten_temp/a.out.js) > 6. The largest testcase I've tried on so far is autovectorization on the > Linpack benchmark. I've been in touch with Heidi who has provided some more > benchmarks, I think they would need to be converted from the SSE SIMD API > into the more generic one, but I am not sure if all those benchmarks need > fits in the JS API. Also not sure if we can't 'polyfill' the SSE API (or a > part of it) using the simpler JS-compatible one somehow, if that were > possible, we could perhaps avoid manually converting benchmarks? > 7. Using the explicit float32x4/uint32x4 types in C does not require any > special compiler settings. The LLVM autovectorizer on the other hand is off > by default, to enable it you need > > --llvm-opts "['-O3', '-vectorize', '-vectorize-loops', > '-bb-vectorize-vector-bits=**128', '-force-vector-width=4']" > > , see test_simd in tests/test_other.py for an example. I am considering > adding an option to emcc such as --autovectorize which would add those 4 > instructions, thoughts? (Perhaps it should always be on, once this is > stable?) > > So overall this is basically at the point where we can start to test > compiled C code using the polyfill and/or JS engine support, when ready. > > - Alon > > > """ > > > I see the slide with the types he's suggesting. >> > > ("he" => me; hello.) > > > Are there types for the int8/16/32, and uint8/16/32? >> >> var foo = 0: float32; >> > > No one is proposing type annotations a la ES4 or TypeScript, note well. > > Indeed although I call out float32 and int32/uint32, it makes sense to > have value objects for all the sized int and IEEE-754 floating types. > > > 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. >> > > Thanks :-). You're right that extant code on the Web might use float32 as > a function name, but that's ok. As usual, JS's bindings in the global > object are writable or otherwise replaceable, to allow user definitions to > trump emergent built-ins. Object detection, e.g., something like > > if (!this.float32) > var float32 = function (x) {...}; > > may fail, but anything object detecting float32 should want what we aim to > provide here -- if that name were used for a function with a different > signature and semantics, I'd be sad but we would probably try to evangelize > such object-detecting content. > > It's extremely unlikely that anyone wrote a detection pattern for the name > 'float32' without anticipating what I've been talking about lately, anyway. > > Still, I've learned the hard way to never say never on the Web. I've seen > almost every common name used in the global object's scope, and not always > as one might expect. If we do run into a hard compatibility problem of the > object-detection-for-**mismatching-signature/**semantics kind, we can use > a built-in module. Indeed it may be better to do that anyway, although the > typed arrays, Int8Array, etc., are all in global scope and require no > import. If we do use a built-in module, then you'd have to say something > like > > import {int8, int16, int32, int64} from "@valueobjects"; > > where the "@valueobjects" name is a place-holder that may or may not be > spelled anything like that. > > > 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). >> > > See https://github.com/dherman/**float.js<https://github.com/dherman/float.js> > . > > > I assume they're adding Uint64Array and Int64Array with his proposed >> changes which would provide a solution for the bitwise conversion. >> > > Yes, we want 64-bit scalar and typed-array objects, both. > > > 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? >> > > I've written quite a bit about the problems adding static typing to JS > ("strong typing" is ill-defined, it was used by marketeers in the past and > that hurt). A fairly recent es-discuss thread: > > http://esdiscuss.org/topic/**optional-strong-typing<http://esdiscuss.org/topic/optional-strong-typing> > > Quoting myself: > > "ES4 failed in part because of AS3 namespaces (from original JS2/ES4 > namespaces in 1999, also in JScript.NET in 2000, IIRC; inspired by Common > Lisp symbol packages), but also because on the Web it's very hard to know > /when/ to typecheck. Code loads all the time. Judgments may be invalidated > down the road. The "any" type requires runtime checking." > > /be > > > ______________________________**_________________ > es-discuss mailing list > es-discuss at mozilla.org > https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss> > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20131027/4a557501/attachment.html>