Closed KSXGitHub closed 6 years ago
I would be wary about messing with the expectation that is
in LiveScript means ===
. The NaN handling behavior is an unfortunate gotcha, but I worry that changing it now would lead to other unfortunate gotchas (for much the same reasons, I presume, that ECMAScript (or, I guess, the browser makers that ECMAScript standardized) didn't change the meaning of ===
and instead created a new function).
You might be interested in infix function syntax? You can approximate what you want with foo `Object.is` bar
, or even:
eq = Object.is
foo `eq` bar
@rhendric I didn't expect this to be in version 1.x. May you consider this in v2.0?
probably, "in" may be upgraded without impact?
foo in bar
current function produce:
function in$(x, xs){
var i = -1, l = xs.length >>> 0;
while (++i < l) if (x === xs[i]) return true;
return false;
}
and there is Array.prototype.indexOf() which may be used: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/indexOf?v=example
by the way, i didnt find in docs about JS/ES version compatibility. is it assumed that version is 1.3?
@KSXGitHub The short answer is that there probably won't be a LiveScript 2.0, although there are a number of us who would be interested in contributing to a successor language that won't be called LiveScript.
@determin1st If you're suggesting that in
should support NaN
, I agree, that's a change I'd be willing to get behind. Please request this in a new issue?
LiveScript's target is ES3 for all features that don't by their nature require higher versions, like yield
. https://github.com/dk00/livescript-next is a promising project that replaces LiveScript's backend with Babel and supports more modern language features, but this isn't part of official LiveScript right now.
it appears, that indexOf() doesn't catch NaN. im trying to avoid NaNs.
i looked in livescript-next and didnt understand why BABEL was used. is something wrong with code structure in LiveScript that makes it hard to comply to new features?
JS/ES has special "use strict" expression which may be (or not?) cloned into LS with modification, for example, "use strict, ES5", and then new functionality will be applied to produced code. it looks simplier.
It's hard to support new target language constructs while still supporting translating those constructs into older target languages, no matter how good your code structure is, if the language features in question are even a little complex. Babel solves that problem. But if you have questions about the design of livescript-next, you should raise them over there; I'm not an expert on that project.
LiveScript
Expectation
or even better
Current behaviour
What's the different?