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

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

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

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

Ответ 1

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

Ответ 2

null, null, null и null

Ответ 3

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

Ответ 4

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

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

Ответ 5

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

И целые "давайте жениться на объектах с функциональным программированием, потому что java работает только с объектами".

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

Если вы посмотрите на него, без JVM не будет Scala, потому что большинство компромиссов просто не имеет смысла, если выходить из контекста бесшовной интеграции с java-миром.