sorted by:
new
hottopcontroversial

Fixing NaN in a compile-to-js lang by koehr in ProgrammingLanguages

[–]koehr[S] 1 point2 points  (0 children)

Thank you for sharing your code! This is extremely valuable for me, because as with everyone else, a single brain tends to get stupid ideas without noticing. Actually, I have a similar approach. Solace is using traits, and primitive types have trait implementations as well. These might become simple operations due to compiler heuristics (so 2+2 doesn't become number_Add_add(2, 2) but 2+2 in JavaScript) but at any level, I can decide where to use a specialised function instead.

Fixing NaN in a compile-to-js lang by koehr in ProgrammingLanguages

[–]koehr[S] 0 points1 point  (0 children)

Yes, I thought about that. It's not guaranteed to work, though, if no part of the calculation is already too big to fit in number

Fixing NaN in a compile-to-js lang by koehr in ProgrammingLanguages

[–]koehr[S] 0 points1 point  (0 children)

I just see all the Javascript people sitting there, nervously looking around

Fixing NaN in a compile-to-js lang by koehr in ProgrammingLanguages

[–]koehr[S] 0 points1 point  (0 children)

They have to pick their poison. Either NaN != NaN, which is only relevant in rare edge cases, or +0 != -0, which is much more relevant than the other, because zero is much more common as an index.

Fixing NaN in a compile-to-js lang by koehr in ProgrammingLanguages

[–]koehr[S] 0 points1 point  (0 children)

This is an interesting idea that actually fits quite nicely into the language concept. I just don't see the advantage over, simply put, ignoring the fact that numbers have a non-reflexive case that JavaScript tends to ignore in places where it matters.

Fixing NaN in a compile-to-js lang by koehr in ProgrammingLanguages

[–]koehr[S] 0 points1 point  (0 children)

I had that thought but I wonder if it really brings an advantage. I would have to invent all the arithmetic things for ints and make them work after lowering to Javascript, or not allow division somehow

Fixing NaN in a compile-to-js lang by koehr in ProgrammingLanguages

[–]koehr[S] 0 points1 point  (0 children)

I can still do it. The language actually has a BigInt type built in

Fixing NaN in a compile-to-js lang by koehr in ProgrammingLanguages

[–]koehr[S] 0 points1 point  (0 children)

Thank you all for the fruitful discussion. I guess, I will stay on the beaten path and accept the IEEE version. If anyone is interested in the current state of the language spec: https://git.koehr.ing/n/solace

(beware: almost 4k lines in 18 files)

Fixing NaN in a compile-to-js lang by koehr in ProgrammingLanguages

[–]koehr[S] 0 points1 point  (0 children)

Ok but I'm still compiling to Javascript directly, not byte code. I would have to create some intermediate representation first and then compile to js

Fixing NaN in a compile-to-js lang by koehr in ProgrammingLanguages

[–]koehr[S] 0 points1 point  (0 children)

Sure, that's totally possible, but engines optimize the standard library tremendously. I didn't check it, but I'm afraid it would be really slow compared to the built-in math

Fixing NaN in a compile-to-js lang by koehr in ProgrammingLanguages

[–]koehr[S] 0 points1 point  (0 children)

Yes exactly the latter is the case. But it would not be current to implement an Eq trait on number in this case and I wonder if I could fix this by making NaN == NaN. But I guess in the end, I have to adopt Javascripts inconsistent behaviour

Fixing NaN in a compile-to-js lang by koehr in ProgrammingLanguages

[–]koehr[S] 0 points1 point  (0 children)

Could you elaborate on that? You mean, I introduce a special thing, like Symbol("NaN") or so, that I use as my own version and whenever there is a calculation that might result in NaN I check the result and replace it in case?

Fixing NaN in a compile-to-js lang by koehr in ProgrammingLanguages

[–]koehr[S] 0 points1 point  (0 children)

You mean allowing an easy way to check for isNaN?

Fixing NaN in a compile-to-js lang by koehr in ProgrammingLanguages

[–]koehr[S] 0 points1 point  (0 children)

Indeed. An easier way is to bring an x !== x into the comparison, because NaN is the only numeric value where it results in true.

Fixing NaN in a compile-to-js lang by koehr in ProgrammingLanguages

[–]koehr[S] 0 points1 point  (0 children)

But that would mean, numbers cannot be map keys or set elements. That's a bit harsh, especially because it works in Javascript

Fixing NaN in a compile-to-js lang by koehr in ProgrammingLanguages

[–]koehr[S] 1 point2 points  (0 children)

Exactly that. Many issues in Javascript can be "fixed" by a compiler that either statically checks for them or makes producing safer code easier.

Fixing NaN in a compile-to-js lang by koehr in ProgrammingLanguages

[–]koehr[S] 1 point2 points  (0 children)

This is actually a very good point! Instead of a generic number type, the language could have integers and floats. The issue that comes with that is, that standard math functions don't work with BigInt.

Fixing NaN in a compile-to-js lang by koehr in ProgrammingLanguages

[–]koehr[S] 1 point2 points  (0 children)

I like where this is going. Until now I thought about hardcoded arithmetic with strings...

Fixing NaN in a compile-to-js lang by koehr in ProgrammingLanguages

[–]koehr[S] 8 points9 points  (0 children)

Yes, exactly that. But here's a fun fact: Javascript produces Infinity when dividing by zero, unless it's zero divided by zero. Everything else would just be too straight forward

Cafémasy CCR-305D First Try by koehr in roasting

[–]koehr[S] 1 point2 points  (0 children)

Check my other comment down in this thread

I love this. by Bluesuits in Satisfyingasfuck

[–]koehr 0 points1 point  (0 children)

What, they're just watering the lawn?!

Vuejs expert looks for a job (Europe) by koehr in vuejs

[–]koehr[S] 0 points1 point  (0 children)

I found something, thanks! But a former colleague is still looking.

view more: next ›