Hi everyone
this is example provided in the docs:
operator >>= left 1 = (left, right) => {
return #`${left}.then(${right})`;
};
fetch('/foo.json') >>= resp => { return resp.json() }
>>= json => { return processJson(json) }
fetch("/foo.json").then(resp => {
return resp.json();
}).then(json => {
return processJson(json);
});We as humans should expose ourselves as much as we can to different ideas and frameworks, doing this makes us wiser and more experienced. We then can use our experience to build better and more sophisticated solutions.
That's why
Hi again, I feel I've caused confusion within the community.
It is not about the intuitive-ness of the >>= operator, and I'm not even trying to compare this library to Nim. Of course, I know about Nim's macros and metaprogramming capabilities (I wrote iterrr).
One of the most interesting things depicted in the example code is the statement: operator >>= left 1 = (left, right) => ... I wonder if anyone has ever been curious about this before blaming me.
According to the documentation link that I included in the first message:
The associativity can be either left or right for binary operators and prefix or postfix for unary operators. The precedence is a number that specifies how tightly the operator should bind. The built-in operators range from a precedence of 0 to 20 and are defined here.
It provides AST manipulation, hygienic metaprogramming, and the ability to define operators; and honestly, I appreciate the effort that was put into making this possible in a language that didn’t originally have this concept at all.
Couple years ago I created ruby like language by altering CoffeeScript transpiler and using some JS AST transformations. It took around moth and worked quite well.
The language was success - any object extendable, operator overloading etc. things like b=A*x (matrix multiplication) it was feature complete real language with quite nice syntax (CoffeeScript like) and Ruby-like object model and standard library, and - with the native JS performance. I even made small project (personal health records managements) with it. I abandoned it because a) it had no types and I like TypeScript safety b) there's no money in it and maintaining is a burden.
What I meant - it was impressive how simple it was to use CoffeeScript compiler and alter it to make another, quite different language (although with similar syntax).
How it's related to Nim - maybe Nim can benefit by simplifying compiler codebase, decoupling it into small standalone project, and allowing anyone to learn it in week or two and contribute. Radically speeding up language progress and new feature development.
I wonder if anyone has ever been curious about this before blaming me.
No one is blaming you :-) I'm just confused and genuinely trying to understand your post.
Thanks for the clarification. I can now see that you're impressed not with the operator itself but with the way Sweet lets you define operators.
Also, I now understand that you just wanted to share something that you liked and it has nothing to do with Nim. Which is totally fine! I just didn't understand it at first.
Maybe we need a separate forum category like Random to avoid confusion in the future?
Maybe custom postfix functions can be supported one day?
? before optional type looks clunky
How it's related to Nim - maybe Nim can benefit by simplifying compiler codebase, decoupling it into small standalone project, and allowing anyone to learn it in week or two and contribute. Radically speeding up language progress and new feature development. Most important - decoupling the language from the runtime. So contributors don't need to understand the Nim runtime to contribute to the Language. And improve stability - clearly localise and separate bugs in language from bugs in runtimes, don't mix it together. And simplify IDE integration - as IDE don't need to know anything about runtime.
You are describing our Nimony project...