parenthesized syntax

[pepa65]

Just dropping by to say how awesome RapydScript is!
One thing stood out: the unorthodox/paradigmbreaking parenthesized syntax:

(def(a, b):
    # stuff
)(1, 2)

I loved the .apply() and .call() innovations, why not have a third function like .do() so you can dispense with the completely unpythonic bracket syntax and write:

def(a, b):
    # stuff
.do(1, 2)

[atsepkov]

hey pepa65, glad you're enjoying the project! I don't have any objections to your solution, just need to think through all the edge cases before dropping something, I do believe the (def() ...)(args) syntax comes in handy in a few other places that I'd need to dig deeper for.

Unfortunately, this project is lately not getting as much attention from me as it did in the past simply because I have a job and a family now and I don't see a way to monetize something like this to work on it full-time. @valq7711 has been maintaining it in the meantime. The nice thing is that the project syntax is generic enough such that it doesn't really show its age much even with ES6, but it definitely would be nice to introduce some new enhancements, simplify the code-base, and remove some dependencies/boilerplate in favor of native solutions.

For example, I'd love to someday get to the following:

• rip out all logic for generating backwards-compatible ES5, even babel can probably be done away with, let's just compile into typescript w/ optional static typing and automatic type inference
• automatic type inference was another project I worked for a while alongside this one (called it Interstate as a pun, because it tracks state) but never ended up getting it finished (too many edge cases). I can open the other project up to the public if there is any interest in it. If finished, the idea was to have it be promise-based so it can backwards-resolve types for variables it already saw earlier but didn't have enough information to identify - TypeScript can't do this, it wasn't designed for this because it's a bit of a brainfuck to code that way. That, and banning reuse of variables for different data types gets you surprisingly close to being able to identify types without making your javascript look like java (which is my main pet peeve with TypeScript)
• operator overloading without function wrappers that add overhead. I believe this is possible already, as long as user accepts possible performance overhead for being too vague with the types and annotates them when possible, RS could compile them to function unless the types are identified, then unroll them into base operations, the compiler already does the same logic quite well for deep-equality operator, where compiler manages to replace it with much-faster identity operator from types alone at compile time. The other 10% of the cases, it falls back to an approach that still saves the expensive function call overhead when possible.

Anyhow, those are just some ideas if I had more time to work on it. If you have time and want to contribute, I'd love to have you join.

[pepa65]

Thanks for the extensive response! The project looks usable and functional in its current form, and your ideas for improvements make it better, but not a whole lot more functional (except perhaps point 3).
Completely understand about other priorities, for now it's keeping this project in a satisfactory state for you. Cheers!