Like was mentioned, the simplest behavior is treat this as an error case.
Other possibilities include:
(*) extending the length of the short array to match the length of the long array -- padding with zeros on the right -- before adding.
(*) finding all possible sums between pairs with one number from one array and the other number from the other array.
(*) cyclically extending the shorter array (probably not useful in this example, but since the example didn't come with a use case that's difficult to know for sure).
(*) Treating each array as a decimal number (or a number in some other base)
(*) combining the two array as a single list of numbers and summing everything to a single value
and... so on...
One point being that programming languages support arbitrarily complex operations.
Another point being that "sum" in this context carries some understandable ambiguity -- the sort of thing which we usually try to constrain with use cases or examples or similar elaboration.
It's certainly true that, depending on how the code is written, you may not be able to optimize out the language implementation from the compiled program. But that just turns into a link against a library with support for the language for your hypothetical compiled program.
That said, the compiler being hypothetical is a very real obstacle. But even there the problem is not that the language can't be compiled -- it's that no one has bothered to implement a compiler for it.
Anyways, if you throw in some ML type inference, and some tools for characterizing the resulting code and its interfaces, you can generate code from an array language which is quite similar to the code you would get from a variety of other languages.
Numbers (and character) are implemented as arrays with 0 dimensions. Text would be an array of characters with 1 dimension (the number of characters), and generally speaking the dimension of an array is a one dimensional list of non-negative integers. Many array languages also include an array type which is approximately the same as a C pointer to an array, with a bit of jargon thrown in to distinguish a reference to an array from the array itself.
Something like an SQL table in an array language would be implemented as a list of columns (rather than as a list of rows) and a corresponding list of column labels. This has some interesting benefits.
That said, functions in array language are typically not arrays (though they presumably would have a textual representation). So... not everything is an array.
Other possibilities include:
(*) extending the length of the short array to match the length of the long array -- padding with zeros on the right -- before adding.
(*) finding all possible sums between pairs with one number from one array and the other number from the other array.
(*) cyclically extending the shorter array (probably not useful in this example, but since the example didn't come with a use case that's difficult to know for sure).
(*) Treating each array as a decimal number (or a number in some other base)
(*) combining the two array as a single list of numbers and summing everything to a single value
and... so on...
One point being that programming languages support arbitrarily complex operations.
Another point being that "sum" in this context carries some understandable ambiguity -- the sort of thing which we usually try to constrain with use cases or examples or similar elaboration.