W Concepts in Programming Languages John Mitchell pisze, że statyczne sprawdzanie typów jest z konieczności konserwatywne (zbyt surowe) z powodu problemu zatrzymania. Podaje jako przykład:
if (complicated-expression-that-could-run-forever)
then (expression-with-type-error)
else (expression-with-type-error)
Czy ktoś może udzielić nieskomplikowanej odpowiedzi, która naprawdę byłaby kwestią praktyczną?
Rozumiem, że Java zezwala na dynamicznie sprawdzane rzutowania dla takich przypadków:
if (foo instanceof Person) {
Person p = (Person) foo;
:
}
ale uważam, że jest to raczej niedobór języka / kompilatora Java niż problem międzyjęzykowy.
2
Podany przykład Javy jest nieskomplikowanym przykładem statycznego sprawdzania typu, który jest zbyt konserwatywny. Mówiąc inaczej: odpowiedź zależy od tego, jaki system typów masz na myśli. Dla każdego przykładu, który wymyślimy, zawsze będzie system typów, który poradzi sobie z tym przykładem (system typów nie jest zbyt konserwatywny na tym przykładzie). Dla każdego typu systemu zawsze możemy znaleźć przykład, w którym jest on zbyt konserwatywny. Myślę więc, że musisz określić system typów. Jeśli system typów Java nie jest tym, o czym myślałeś, czy jest coś bardziej szczegółowego, o czym myślałeś? Wnioskowanie o typie ML?
—
DW
można argumentować, że przykładem jest statyczna analiza kodu „zachowawcza”, a nie sprawdzanie typów. pomocne byłoby zdefiniowanie „konserwatywnego” . prawdopodobnie wszystkie systemy typu statycznego będą „konserwatywne” w porównaniu do systemów dynamicznych, ponieważ te pierwsze są z definicji bardziej rygorystyczne w czasie kompilacji . jednak można argumentować, że żadne z nich nie jest bardziej rygorystyczne w czasie wykonywania, ponieważ sprawdzanie dynamiczne może również zwracać podobne błędy (oparte na typach). a przy okazji, dynamiczne sprawdzanie rzutów w językach uruchomieniowych w językach nie jest wadą , są one w większości statycznie sprawdzanych językach, być może gdzie indziej możliwe.
—
vzn