-1

The program is:

object Hello extends App {
    
    val a: List[Int] = List(1, 3, 4, 5, 8, 10, 11, 22, 33)
    for (i <- 0 to 11)
        println(a(i))

}

The Output is:

1
3
4
5
8
10
11
22
33
java.lang.IndexOutOfBoundsException: 9 // continues as a long error message.

How did it not detect at the compile time that the index was going to be out of bound? Aren't compiled languages supposed to do this? If no, could you please share what is included in the compile time checks and what's not?

As a newbie, I always hear that, compiled languages are great that they find errors at compile time thus are more robust.

Dmytro Mitin
  • 48,194
  • 3
  • 28
  • 66
lousycoder
  • 451
  • 6
  • 10
  • 4
    Just because something is compiled doesn't make it magically check bounds at compile time. – Jonathan Hall Nov 20 '20 at 14:55
  • 4
    Typed languages are good to catch type errors, but arithmetic and logical errors are harder _(if not practically impossible)_ to catch. On the other hand, **Scala** is also a more declarative language, declarative languages also help to reduce errors for example instead of the imperative for you wrote, you can write a more declarative `a.foreach(println)` which will never fail in runtime for bad bounds _(and is actually much more efficient than your `for`)_ – Luis Miguel Mejía Suárez Nov 20 '20 at 15:02
  • @LuisMiguelMejíaSuárez Yes, that's obvious. My ```for``` statement would be exception free by using ```for (i <- 0 to (a.length - 1))``` – lousycoder Nov 20 '20 at 15:15
  • 2
    @lousycoder the point of a declarative language is that you do not need to think about those things, that you do not need to fix your code for simple details like `-1`. For example, this point is more obvious when you compare things like `map` `filter` and `foldLeft` over their imperative counterparts, and even more when you combine multiple of them. – Luis Miguel Mejía Suárez Nov 20 '20 at 15:18
  • @LuisMiguelMejíaSuárez Yes, I've not yet got used to this declarative style. It's great in the sense that I don't need to take care of minute details. – lousycoder Nov 20 '20 at 15:52

2 Answers2

5

You shouldn't confuse compiled languages (or statically typed languages) with dependently typed languages. Collections not longer than n elements is a typical example of dependent type. A language being compiled means that there are compile-time checks besides runtime checks. Whether to make a specific check (like the check of collection length) runtime or compile-time is your choice (or the choice of language designers or the choice of standard-library designers). And even if a check is compile-time, whether to encode it in types or with different tools is also a choice.

Interpreted vs Compiled: A useful distinction?

Can every language be categorized as either compiled or interpreted?

Can every language be compiled? And can every language be interpreted?

What is dependent typing?

Any reason why scala does not explicitly support dependent types?

Shapeless: Collections with statically known sizes

import shapeless.Sized
import shapeless.nat._

val a: Sized[List[Int], _9] = Sized[List](1, 3, 4, 5, 8, 10, 11, 22, 33)

a(10) // doesn't compile

scastie

Dmytro Mitin
  • 48,194
  • 3
  • 28
  • 66
  • Sir, If I directly put ```a(10)```, then it will result in an error in languages like python too. When I hear or what I've been taught is that in interpreted languages like python, code execution is done line by line. Whereas in compiled languages, code is first checked for errors and if found clean then converted to machine language. So, in a language like python, if exception occurs at the out of bound member when iterating, that makes sense acc. to above bookish definition. But, when this occurs in Scala, I don't know how code gets executed, really. – lousycoder Nov 25 '20 at 14:32
  • 1
    @lousycoder A language being compiled means that there are two stages: compile time and runtime. `IndexOutOfBoundsException` for `List` in your question occurs at runtime. The error for `Sized` in my answer occurs at compile time. Can you see the difference now? – Dmytro Mitin Nov 25 '20 at 14:59
  • 1
    @lousycoder It's true that during compilation your code is checked for errors. But it's checked for some errors, not for all errors. If you try to put `List[String]` instead of expected `List[Int]` such error will be caught by compiler. But if your program calculates `43` instead of correct `42` most probably such error will not be caught by compiler. So using compiled language doesn't mean that you can avoid writing tests verifying how your program executes at runtime. – Dmytro Mitin Nov 25 '20 at 15:04
  • 1
    @lousycoder You can transfer some checks from runtime to compile time. Like using `Sized` or `HList` instead of `List`. But it's not always easy. In principle you can try to encode your business logic on type level and then even errors like `43` vs. `42` can sometimes be caught at compile time. But still some errors (input-output errors, memory errors, connection errors etc.) will remain for runtime. – Dmytro Mitin Nov 25 '20 at 15:09
  • Sir, Thank you for providing a clear picture. It makes sense to me now. – lousycoder Nov 25 '20 at 17:59
4

The main problem here is that for in Scala does not mean the same as it does in other languages. The code in the question is equivalent to

(0.to(11)).foreach(i => println(a.apply(i))

The compiler would have to inspect a number of different methods and infer their behaviour in order to determine that the apply method would throw an exception.

But the main advantage of compiled languages is performance, not error checking. It is strongly-typed languages (which are typically compiled) that provide better error detection.

Tim
  • 26,753
  • 2
  • 16
  • 29
  • Could you please throw more light on the main keywords in your answer: Performance, Strongly-typed? – lousycoder Nov 20 '20 at 15:01
  • 4
    The improved performance comes from the compiler being able to put significant resources into optimising the code, which is not possible for interpreted or just-in-time compiled languages. Strong typing is too complex to discuss here, but there is plenty written about it elsewhere! – Tim Nov 20 '20 at 15:09
  • If a question gets downvotes, should it be removed voluntarily? And what's optimizing the code exactly here? – lousycoder Nov 20 '20 at 15:14
  • 3
    Not sure about the downvotes, I guess it is because the question isn't strictly about a programming problem. Optimisation takes many forms, but a good example would be automatic vectorisation of loops, which is too time-consuming to do with just-in-time compilation but provides a good speed-up. – Tim Nov 20 '20 at 15:55