enhancement: check for already reserved words like: enum about rapydscript HOT 18 CLOSED

RapydScript already defines a list of reserved keywords as JS_KEYWORDS in tokernizer file to which we can append any keyword satisfying this criteria (the result is that your compiled code will add underscore to this variable). However, I don't believe 'enum' is a reserved JavaScript keyword, and I couldn't find a source that confirms otherwise. Are you sure you're not talking about TypeScript? Could you provide an example and a reference showing that it's indeed a reserved keyword.

from rapydscript.

At the moment, RS autofixes names that are js-keywords, but it does it for only 7 keywords. I would like to drop this feature and rise compilation error instead. Does anyone have any objections?

from rapydscript.

@atsepkov-zaius it is es6 keyword - just try enum=123 in the chrom console

from rapydscript.

At the moment, RS autofixes names that are js-keywords, but it does it for only 7 keywords. I would like to drop this feature and rise compilation error instead. Does anyone have any objections?

I would prefer of handling it transparently to the user (as is done right now) rather than raising a compilation error since the compiler doesn't actually need the keyword and can easily handle the issue. Is there an edge case we're not handling you see with current implementation?

Regarding enum, that's weird that it's reserved but serves no purpose. But we should be able to remedy this simply by adding it to the JS_KEYWORDS list. It looks like there are 8 more similar words that are reserved but unused: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Errors/Reserved_identifier

from rapydscript.

@atsepkov The problem is that once we add keyword into autofixe-list we cannot turn it back into keyword, because it will break the existing code

from rapydscript.

@valq7711 The same will be true of any potential future keyword RapydScript implements, regardless of whether it's already used by JavaScript, tying ourselves to JavaScript keywords seems like an arbitrary limitation that only solves half the problem. I do like the idea of implementing a concept of enums and interfaces in the future, however. We can flag those as RS-reserved instead of JS-reserved by adding them to they KEYWORDS list, which would prevent user from using them while giving us ability to implement them in the future without breaking backwards-compatibility.

from rapydscript.

@atsepkov OK, I made the branch https://github.com/atsepkov/RapydScript/tree/valq7711-fix%23216?files=1 that implements the following logic:
if the name is any keyword/reserved_word and it is in JS_KEYWORDS it is autofixed, otherwise it rises an error. I also added new compile option strict_names that is paranoiac mode and prevents using of any keyword as name (it is false by default).
So what do you think?

from rapydscript.

Putting this behind a flag seems fine to me, but I don't understand some of the other changes I see in the branch which don't seem related to this issue, such as modification to how a native JS class name is returned or the logic changes to the "atom" case.

Also, if we're removing ES5 keywords that ES6 no longer reserves (which I'm completely ok with), does it make sense to drop ES5 altogether. My previous reservation about dropping it earlier was a combination of browser support (no longer an issue) and an edge case in how ES6 classes handled instance variables, but if I remember you also added a fix for that last year?

from rapydscript.

JS-native classes:
There is Array.from for example - we don't want RS to fix it to Array.from_, so we need to know what the type of class that property belongs to (it is related to only es5 mode).

Atoms:
At the moment, there are only None True False atom keywords, null true false are treated by RS as normal names! So related to this issue, what should we do?:

• fix true to true_ (really?, there are still a dozen places where it takes place in the compiler itself, I fixed only a couple)
• raise an error
• allow to use both notations, but only as keywords ( considering, that RS is mix of Python and JS)

Removed keywords:
The keywords like double float ... have been removed since ECMAScript 5 (https://www.ecma-international.org/ecma-262/5.1/#sec-7.6.1.1)

from rapydscript.

1. This logic shouldn't be applied to properties like Array.from at all, if it does, that's a bug. Properties should be converted to a different token type.
2. JavaScript is a different language, so I don't see an issue with treating a keyword from it as a regular variable since we already have a Pythonic keyword for the same purpose, it happens all the time with languages, Array/array isn't a keyword in Python either. We do straddle a delicate balance between JS and Python, but in this case we have already picked to be more like Python than JS several years ago. Out of the 3 solutions you suggested, my vote is for #1 for this reason. The alternatives have following drawbacks:
   2nd: we're going back to forbidding arbitrary keywords the compiler really doesn't care about, it's an arbitrary limitation
   3rd: it may seem like a good idea until you end up with a language like Perl. Python advocates consistent and simple code, when we allow alternative implementations of same thing, the code becomes neither simple nor consistent.

from rapydscript.

@atsepkov

1. This logic shouldn't be applied to properties like Array.from at all, if it does, that's a bug. Properties should be converted to a different token type.

As I mentioned, it is related to es5 only, because in this mode method (var) of the class (Foo) is compiled to

var Foo = (ՐՏ_1 = function Foo() {
    }, Object.defineProperties(ՐՏ_1.prototype, {
        var_: {
            enumerable: true, 
            writable: true, 
            value: function var_(){ // the name of the method must be a valid JS-name
                var self = this;
            }
        }
}

So, do you mean, that it should be fixed to value: function(){...}?

2. ... Out of the 3 solutions you suggested, my vote is for #1

OK, I'll turn the atoms logic back

from rapydscript.

@atsepkov
There is a problem with true false null - at the moment they are treated as names but they are not fixed by underscore, so they are used in the output code as is (i.e. True False None).
If we'll fix them - it may break existing code without any compilation errors.

from rapydscript.

@atsepkov
What about the case:

var = 123
var_ = 345

Given that we're only talking about a dozen keywords, I still think it's not worth it.

from rapydscript.

As for me, the exclusive advantage of RS is that code is compiled to js almost one-to-one. So it is very easy to debug/inspect. But with that autofix I should keep in mind that some of identifiers may be changed by compiler, but if I should hold it in mind ... what is the benefit?

from rapydscript.

I see, I didn't realize those weren't fixed by underscore. What worries me about adding null to RS is that it also makes the null vs undefined problem of JS more confusing to the user. Now they have 3 nullish types and have to remember the subtle differences. Let's just have these conversions affected by the flag you added same way as other keywords (and fix them with underscore without the flag).

from rapydscript.

it also makes the null vs undefined problem of JS more confusing

It is the same as None vs undefined
If someone started to use JS, then sooner or later he has to realize the difference between null and undefined. Just for example: in Python function that does not return anything returns None, but in JS it returns undefined. The core difference that in JS it is normal practice to use null as value that does matter, but in Python it is considered as bad solution.

from rapydscript.

@atsepkov

What about the case:

var = 123
var_ = 345

Using underscore for autofixing breaks the code like above. Should we use non-keyboard symbol instead of _?

from rapydscript.

Fixed by #217

from rapydscript.