What should and should not be normalized?

[jiegillet]

I thought it would be a nice idea to discuss ideas on things that should and should not be normalized. I sometimes have ideas and then I convince myself that it should not be done, or I open an issue and close it a bit later (ahem #36), so it might be good to have a trace of ideas.

Here are a couple ideas that I had. Mostly bad ones, but I want to explain why.

All function arguments should receive a new placeholder 🚫

This is #36, but it is specifically mentioned in the documentation of something not to do. I thought that two people with the same solution that only differ with a variable name should represent the same way, but it's not true. If one of the solution has a variable name that is shadowing another, it could be confusing or bad practice, so it should be pointed out when it is.

Anonymous functions should be represented the same way 🚫

The functions &length/1, &length(&1) and fn x -> length(x) end all do the same thing, so they could be represented the same way. However, the readability is quite different, so we might want to point out better options depending on context.

Normalize functions order 🚫

The docs mention "Normalize the order where insignificant" so I thought we could reorder functions, but even the compiler has opinions on how functions with the same name and arity should be grouped together, so we shouldn't touch it.

[angelikatyborska]

I agree 100% that we shouldn't attempt those three ideas mentioned 👍. I'll keep this issue in mind and post here if I get any ideas.

Let me just add to:

The functions &length/1, &length(&1) and fn x -> length(x) end all do the same thing,

Only the last two do the same thing, which is create a new function, the first one captures an existing function. The difference between the last two is also quite big - the capture operator with positional arguments cannot be used when there are no arguments or when not all arguments are used.

[jiegillet]

How about map keys? Should we normalize them? It makes sense for maps that users create, but it could be a problem when using pattern matching from an external function...

Related to maps, one thing we could definitely do is sort the keys so that %{a: 1, b:2} and %{b:2, a: 1} have the same representation.

[angelikatyborska]

How about map keys? Should we normalize them?

Hmm, that's a hard one. I feel like I would need input from other maintainers from other languages to figure this out. Slack?

Related to maps, one thing we could definitely do is sort the keys so that %{a: 1, b:2} and %{b:2, a: 1} have the same representation.

I think this makes sense. I was wondering if that could shadow instances where people assume maps are ordered, but that would be visible by the usage or lack of usage some sorting function calls somewhere else in the solution, so I think it's fine.

[angelikatyborska]

Related to maps, one thing we could definitely do is sort the keys so that %{a: 1, b:2} and %{b:2, a: 1} have the same representation.

Created a separate issue for this: #74