I think the names for the different expression variants can be made clearer, to make it easier for users to grasp.
FYI, at the moment, people who try elm-review
tell me that the hardest part is working with elm-syntax
(which does make sense, since that is a big part of the elm-review
API ).
Application variant
Expression
has a Application
variant.
To this day, I find that name confusing and un-intuitive. I think that something like FunctionCall
would be more understandable (to me at least), especially since with the changes proposed in #43, it would have one argument at the very least (that used to be true before, but this becomes more obvious to the user).
OperatorApplication variant
I think this one makes sense, but I feel like Operation
would be more intuitive, although it could be not clear enough ๐ค
(By the way, maybe for a different issue, but does the InfixDirection
argument bring any value here after post-processing?)
Operator variant
I have no clue what this represents in practice, I think this one should not exist.
Literals
There are several kinds of literals that are not consistent. I think each literal type could be suffixed with Literal
:
CharLiteral
: This one is already good ๐
Floatable
is a bit of an odd name I think. FloatLiteral
is better IMO
ListExpr
-> ListLiteral
- For consistency,
Integer
-> IntLiteral
, Hex
-> HexLiteral
- Lastly:
Literal
-> StringLiteral
. It is not clear that Literal
pertains to strings, so I think it is nice to explicit that.
Other renames
I think the names for expression variants can also be re-thought to be more consistent. A lot of them are suffixed with Expr
, some with Expression
, others with Block
and some are not suffixed, leading to an inconsistent experience.
I think we can remove Expr
/Expression
from most, while still making a lot of sense.
IfBlock
could be renamed to If
(or at least IfExpr
, since the Elm guide calls them if expressions)
UnitExpr
could be renamed to Unit
. I don't think there is any confusion here
TupledExpression
-> Tuple
. Although this could conflict with the proposal I made in #49 when people import everything with (..)
. So either we discourage doing so, or this could be named TupleExpr
ParenthesizedExpression
-> Parenthesized
? Not entirely sure about this one, but I think it makes sense
LetExpression
-> Let
(I personally like LetIn
, but that's not what other people call those)
CaseExpression
-> Case
(I personally like CaseOf
, but that's not what other people call those)
LambdaExpression
-> Lambda
RecordUpdateExpression
-> RecordUpdate
GLSLExpression
-> GLSL
?
Some context
FYI, I tend to import and use elm-syntax
expressions like this:
import Elm.Syntax.Expression as Expression exposing (Expression)
foo = case Node.value node of
Expression.RecordUpdateExpression -> ...
So that it becomes easier to know where a value comes from, which I feel can become overwhelming otherwise. When doing so, having names like Expression.RecordUpdateExpression
becomes a mouthful that does not add any additional information.
I wouldn't be against suffixing some variants with Expr
/Expression
as they are now, but I am not sure that would bring a lot of value.