fix array access

[kikofernandez]

This commit fixes accesses to an array when the type is different from an array; closes #823 and #831

This test case used to crash the compiler

active class Main
  def main(): unit
    val i = 4
    i(0) = 3
  end
end

With this commit, the compiler informs you that it expects an array of a function call and you gave it an int type.

[EliasC]

Looks straightforward enough (especially when reviewed with ?w=1). I only have a minor comment on the error message, but I would be fine with merging it anyway. Will merge this afternoon unless anyone objects.

[EliasC]

Minor: Should this be "an array or a function"? This way the error message becomes

Expected an array or a function but found expression of type 'int'

reflecting that the type error is not the whole expression, but only the sub-expression that is being called.

[kikofernandez]

thanks! I have remove the access word from the error message

[EliasC]

Have you also pushed?

[EliasC]

This test needs to be updated as well

[albertnetymk]

It seems that unless (isArrowType ty) is guarded by an if with the same condition.

[EliasC]

Here is the thing that could go according to @albertnetymk. I agree.

[kikofernandez]

good catch @albertnetymk and @EliasC. Fixed!

[albertnetymk]

OK, then it makes sense to restructure the flow to be sth like the following to "return early" for abnormal case, IMO.

   unless (isArrowType ty) $
    error
   -- normal case follows

[kikofernandez]

@albertnetymk I thought about it and considered that the majority of the time the programmer knows that an array is an array, so I was favouring the other pattern, where the developer is correct in most occasions. I have no problems going for your suggestion though.

(@albertnetymk it would be great if your comments are actually part of the review or marked in the appropriate lines, as the ones from @EliasC)

[EliasC]

I agree with Kiko. Having the failing case last makes sense to me.

[albertnetymk]

By "return early", a level of indentation is removed, which is considered a decrease in certain complexity metrics. Surely, this is very subjective; the author should make the judgement call.

[EliasC]

By "return early", a level of indentation is removed

The same "complexity reduction" could be achieved by writing

else if ... then
  ...

instead of

else
  if ... then
    ...

[albertnetymk]

The same "complexity reduction" could be achieved by writing

I don't think that's true in Haskell, because body needs to be indented further than if.

[kikofernandez]

This is a matter of taste and style. We all have provided good reasons for choosing one option or the other. Can we please move past the if-else?

[EliasC]

I took an executive decision and merged this =)

[albertnetymk]

The "early return" is about a taste of preference, but the indentation discussion is not.

My previous statement, "body needs to be indented further than if", is incorrect. The following is perfectly valid Haskell code:

f =
  if True then
 1
  else if True then
 2
  else
 3

[kikofernandez]

Perfect valid Haskell code ≠ accepted code in Encore compiler