Какая функциональность / функция в Scala существует только как уступка базовой платформе и должна быть удалена, если она предназначена для чего-то другого?

Question

Некоторое время назад я читал о Scala для LLVM , и я продолжал задаваться вопросом, какие вещи в языке / спецификации / библиотеке Scala существуют только для того, чтобы JVM радовалась или улучшала взаимодействие с Java.

Учитывая, что запуск Scala на LLVM предоставляет гораздо больше свобод, и план состоит в том, чтобы перенести язык (а не всю экосистему Java вокруг него), какие функции там не имеют смысла?

Руководство: яинтересуются такими вещами, как Object#finalize, монитор (notify, wait), clone против Cloneable, отсутствие индексов 64-битных массивов, размеры коллекций ограничены 32-битными, java.lang.String, Javaотражение, ...

Answer 1

ноль, ноль, ноль и ноль

Answer 2

Тип стирания. Наличие у каждого объекта ссылки на монитор (ужасная ошибка Java).

Answer 3

Ветвь типа AnyVal может гореть в вечном огне ада. Массивы могут быть реализованы разумным способом (хорошо, теперь уродство скрыто довольно хорошо), то же самое для типов с ограниченным доступом. Методы clone, hashCode и toString могут входить в классы типов, к которым они принадлежат. Карринг может быть реализован без нескольких списков аргументов. Вывод типа и программирование на уровне типа может быть улучшено.

Answer 4

Я надеюсь, что порт Scala для LLVM включает определяемые пользователем типы значений (например, struct типы в CLR).Проблема заключается в том, чтобы избежать выделения кучи.Например, в научных вычислениях существует необходимость в абстракциях, таких как массивы комплексных чисел, но выделение кучи каждого комплексного числа слишком дорого (с точки зрения пространства и пропусков кэша).

Редактировать : Возможно, JVM тоже получит типы значений.Джон Роуз, инженер JVM, обсуждает , как можно добавлять типы значений.Есть недавние слухи о том, что Oracle планирует добавить типы значений для лучшей поддержки высокопроизводительных вычислений.

Answer 5

Синтаксис, в основном, чтобы не отпугнуть существующих разработчиков Java.

И весь «давайте объединить объекты с функциональным программированием, потому что Java работает только с объектами».

Без необходимости интеграции св существующих библиотеках OO не было бы необходимости кастрировать вывод типов, чтобы создать некрасивый ключ в форме классов case для поддержки сопоставления с образцом.

Черт возьми, если вы посмотрите на это, без JVM не было бы Scala, потому чтобольшинство компромиссов просто не имеют смысла, если их вырвать из контекста бесшовной интеграции с миром Java.