Hi folks, first post here, but I've been around #nimrod for some time.
After a recent talk with Araq, I'm investigating Nimrod for a project for which Nimrod's ability to compile to both native and web technologies are key. By re-reviewing Nimrod after a long time, I'm reminded of both things I like, and things I don't. In the case of the later, I have written some minor** suggestions in a github gist to see what others in the Nimrod community think about my ideas.
Please read the gist here: https://gist.github.com/PhilipWitte/6648742
While I suggest three separate features in the file, my main focus is on the Reverse-UFCS point, with the ultimate goal of making Nimrod a more attractive language to programmers, like me, who prefer empirical style to functional. Any comments, questions, or criticisms on my suggestions are welcome.
**Not actually sure how "minor" these suggestions would be to implement.
I like the type syntax proposed, the init constructor...mmm...I'm not sure... Araq mentions the func keyword for procs without side effct, for me would be cool the "def" instead, would be more similar to python,ruby,scala...but seems than araq hates this word lol
I'm not sure how open would be araq to changes in the sintax, so I prefer to adapt to the existing syntax and does't wait for big changes
Thanks for the feedback. Also, adrianv, thanks for the code. I was trying to do something similar to your declClass when I was using Nimrod before, but couldn't figure out all the AST manipulation. I will probably be attempting something similar when porting my existing JS code to Nimrod later, and your code should be a great help (or i may end up just using your code directly as it seems to do what I want, i see it's GPL2).
I have more to discuss about these issues, as I'm still convinced there's value to them. Also, while yes, the reverse-UFCS is technically just syntax sugar, so is regular UFCS.
That said, I want to get a better grasp of Nimrod again before I get into these arguments too deeply. I wont be porting of my code till at least the end of October or November, and I'll use the time in-between to do some tests of my own. Just wanted to put this out there to get some feedback from the Nimrod community. Thanks again.
Araq mentions the func keyword for procs without side effct, for me would be cool the "def" instead, would be more similar to python,ruby,scala...but seems than araq hates this word lol
'Hate' is a strong word, it's an irrelevant syntactic detail. However it doesn't make too much sense to use 'class' for 'define class' and 'def' for 'def'ine method'.
Just as 'result' is automatically defined within procs which return a type, 'this' could be automatically defined as an parameters for procs which are defined with a type prefix.
'this' is verbose, I prefer 1 letter parameter names for these things. In fact, I also consider 'result' too verbose but didn't have the guts to name it 'res' or 'r' ... ;-)
Also I wonder why the 'template `@`(x: expr): expr = this.x' is not widely used by now: lets you use @field instead of 'this.field'. Come on people, it's Ruby-like! You have to like it!
@filwit: Hope the code will help you. The license shouldn't be a problem - I will release it to any you like or need. AST manipulation is a little bit cumbersome at the moment - and I didn't comment the code...
When I started with nimrod I also had the feeling that it should be more OOP like. But when you get used to nimrods generic power, you will see that its design is quite good like it is now.
(this as Person).greet()
another variable similar to 'this' could be added called 'base' as-needed; base.greet() ;)