initial feedback / various features #2023
Closed
ScottFreeCode
started this conversation in
General
Replies: 1 comment 1 reply
-
Thanks for the feedback, in response to your points: Rec KeywordWhile this could be inferred, it helps to ensure safety and prevent errors, as care should be put into recursive and mutually recursive functions in order to not overflow the stack, such as using tail calls. Comma Between DeclarationsIn the next release (v0.6.0) we switched the
|
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
So first I just gotta say… cool project. Looks like JavaScript, feels kinda more like one of the strongly typed purely functional languages – or JavaScript cleaned up in that general direction. Very nice!
A few things that popped out at me as a little odd, coming from a relatively mainstream background, skimming the docs:
Rec keyword: can't functions be inferred to be recursive or not based on whether they call their own name?
Comma after a type to allow it to be mutually recursive with the next type… Very easy to miss that comma. In a lot of languages, an optional punctuation in a place like that where you could end the type and the line and start new stuff on the next line, or you could delimit the two even though you don't have to, is the sort of thing I'm used to glossing over. And even if it weren't, it's so… small and not in a position where it stands out, IMO.
Required
else
branch. This strikes me as weird, if Grain allows side effects. Do I write an else just to say it's empty and should do nothing? (Incidentally, it isn't immediately obvious to me whether Grain uses something like async/promises/IO that can perform external side effects. But it does have opt-in mutation, including the+=
etc. sorts of operators that don't return a value. So I could see a case where an if branch performs a mutation, if nothing else.)I kinda sorta get that if needs an else branch if it is used in an expression or a function return. And… oh, that the last thing in a function is always a return… Y'know, not sure how I feel about implicit return of the last statement/expression – I know it's pretty unambiguous and very functional (I want to say I saw that in Lisp), but it does lead to weirdness like "your if expression is getting returned even if you meant it to perform a side effect, therefore your if needs an else even if you don't intend to use the value for anything."
I don't suppose there might be some other way to make that… neater? Maybe make returns explicit or maybe allow an optional explicit "this function doesn't return anything" indicator (put
void
at the end of the function?) and then allowif
to have noelse
if it is not used in another expression or as a return value?I'll admit I'm basically backseat driving here as I'm just relating what pops into my head quickly reading the intro/guide doc with completely fresh eyes. I'll also admit I don't know whether I'm going to switch to Grain right away, or when I'll personally have a good use case – generally my web projects are best off in straight JavaScript (maybe I don't know enough about what WebAssembly is for?). So this is really not a a demand that anything change things to suit me; just feedback on what first impressions can be like / thoughts from a complete novice.
Best of luck to y'all in pioneering a new language! The idea here of staying familiar to JavaScript programmers but doing types much more like a functional language is a really solid one and I hope it catches on.
Beta Was this translation helpful? Give feedback.
All reactions