scala 2.9: планы вывода типов параметров функций с параметрами по умолчанию?

Question

Я только начинаю со Scala. Я использую Python для исследовательского программирования, и я конвертирую довольно большую (~ 4000 строк) программу Python.

Несколько комментариев:

1. Похоже, что сейчас самое подходящее время для участия в Scala, так как много нового было добавлено в 2.8.
2. С другой стороны ... Интересно, почему у Scala нет приличного пакета ввода-вывода и почему это не кажется приоритетом. В большинстве языков IO считается одной из самых фундаментальных операций, и части языка обычно разрабатываются специально для того, чтобы IO работал хорошо. Например, библиотека ввода-вывода в Python кажется одной из самых старых и стабильных частей языка (по крайней мере, в его интерфейсе). Тем не менее, комментарии двухлетней давности говорят о том, что «Source.fromFile () - хакерский взлом, подождите, пока такой-то и завершит новый пакет ввода-вывода», - и я не вижу движения к завершению этого. Еще хуже тот факт, что Source.fromFile (). GetLines () - который, взломать или нет, является широко рекламируемым интерфейсом - был полностью сломан изменениями, внесенными в 2.9.0.1 (см. https://issues.scala -lang.org / просмотр / SI-4662 ). Очевидно, что для этого самого базового интерфейса ввода-вывода вообще нет регрессионного тестирования, что является плохим признаком.
3. Тип erasure отстой так ужасно, что я действительно удивляюсь, почему в Scala было принято решение вставить его. Да, я знаю, что в Java есть стирание типов, и Scala построена на JVM, но в результате нужно добавить явно видимые вещи, такие как манифесты, аннотации специализаций и т. д. и т. д., чтобы обойти стирание типов, просто пахнет очень плохо ... В конечном счете, я чувствую, что дизайнеры Scala осознают всю глупость этого процесса и будут вынуждены реализовать правильную универсальную типизацию, при которой то есть у них будет много лишних слов, чтобы их осудить.

Мой вопрос:

Планируется ли добавить вывод типа для параметров функции с аргументами по умолчанию? Писать что-то вроде этого немного раздражает:

  def add_words(words:Traversable[String], ignoreCase:Boolean=true,
                stopwords:Set[String]=Set[String]()) {
    ...
  }

В этом случае аннотации типов для ignoreCase и stopwords просто не нужны, и они просто добавляют ненужное многословие.

Спасибо за любые комментарии от тех, кто участвует в разработке Scala.

Answer 1

1. В Scala уже давно добавлены хорошие вещи, но, по мере того, как они набирают популярность, они становятся все более стабильными. Люди, которые были до версии 2.8, имели гораздо больше возможностей для изменения языка, чем люди в наши дни - и потому, что они представляли больший процент пользователей, и потому, что язык был более гибким.

   Возьмите, к примеру, вашу проблему с стиранием. Как пользователь 2.0, у вас будет гораздо больше шансов сделать что-то с этим, чем сейчас. Фактически, влияние, которое окажет совместимость, в значительной степени является гарантией того, что этого больше не произойдет, если только Java не приведет.

2. Вы пришли из языка сценариев. Языки сценариев очень сильно связаны с вводом / выводом, потому что это их масло и хлеб. Для Scala любые серьезные операции ввода-вывода просто передаются библиотекам Java - в этом и заключается смысл совместимости Scala с Java.

   Кроме того, ваша характеристика 4662, на самом деле, совершенно неверна. Он не был сломан вообще , хотя изменение поведения сделало возможно некорректно работающий код снова. Это вкратце 4662:

   val source = scala.io.Source.fromFile(new java.io.File("test1.file"))
   use(source)
   val lines = source.getLines
   

   Поскольку source является Iterator, он исчезнет, ​​как только вы его используете. Это было совпадением, что вы могли использовать его повторно после вызова toString, а не внутренней гарантии.

3. Тип стирания не так уж и плох. На самом деле, это признак плохого дизайна, если он мешает - вы не должны проверять, что это за тип, а вызывать методы и позволить it обрабатывать себя. Не сказать, что это не раздражает время от времени, но не так плохо. Увы, это фундаментальный выбор, обеспечивающий полную совместимость с Java, и он был сделан очень осознанно. Я не вижу, как Скала ведет из этого.

   Одним из новых языков, которые обещают избавиться от стирания и поддерживать совместимость с Java, является Цейлон. Если Цейлон справится с этим, и я твердо нахожусь в лагере сомневающихся, тогда Скала может последовать за ним.

   Кроме того, в недавнем обсуждении замыканий для Java 8 указывалось на возможность того, что что-то можно сделать с удалением. Если это окажется правдой, то Scala тоже сможет заработать.

Что касается вопроса, я согласен, что эти типы могут быть выведены. Однако я не уверен, что кто-то что-то делает с параметрами по умолчанию - приоритеты на данный момент находятся в другом месте.

Answer 2

1. Да

2. Поскольку базовая виртуальная машина абстрагирует любой доступ к миру «извне», в основном существует возможность либо поставлять скомпилированный код, делая Scala не зависящим от платформы, либо используя такие вещи, как java.io.File, который просто полностью нарушен , Java 7 (спустя всего лишь 15 лет) наконец-то добавила некоторый пригодный для использования API файловой системы, который, насколько мне известно, находится в процессе разработки библиотеки Scala IO. Другой момент - поддержка других платформ времени выполнения. Не стоит выпускать библиотеку Scala IO, которая имеет только реализацию JVM. Итак, в основном: наличие некоторой приличной библиотеки ввода-вывода стало возможным благодаря Java 7 несколько недель назад. Учитывая, что Scala не откажется от поддержки Java 6 (и 5) в ближайшем будущем, не ожидайте, что IO-поставка со стандартной библиотекой скоро будет.

3. Вы используете это неправильно. Но не стесняйтесь создавать свой собственный язык, который делает все лучше, если вы думаете, что «дизайнеры Scala осознают глупость». Реферические дженерики трудно комбинировать с типами с более высоким родом. И если бы мне пришлось выбирать, я буду каждый раз использовать HKT над усовершенствованными дженериками.

Ааа .. верно. Эти вещи не твои вопросы. Ответ на актуальный вопрос:

Это может быть сделано, но людям нравится соблюдать простые правила. Так что, вероятно, нет.

Answer 3

У меня недостаточно мощности для добавления этого комментария, поэтому я должен добавить его в качестве ответа. Также это слишком долго для комментария.

Что касается основного вопроса, я согласен, что типы входных параметров со значениями по умолчанию могут быть выведены. Я выполнил следующий запрос на их трекере проблем с Scala и не нашел подходящего запроса. Так что, возможно, вы могли бы подать один там.

project = SI AND (сводка ~ "по умолчанию" И сводка ~ "значение")

1. без комментариев
2. без комментариев
3. Как уже отмечали другие, реификация (то есть не стирание типов) затрудняет реализацию генериков с более высоким родом. Вот прямая цитата из раздела 6.1 «Генерики высшего сорта», Писсенс, Мурс, Одерский.

Поскольку Scala использует стирание типов в бэк-энде, степень Изменения ограничены проверкой типов. Понятно, что наше расширение таким образом не влияет на характеристики программы во время выполнения. По иронии судьбы, поскольку стирание типов является корнем других ограничений в Scala, это было важное преимущество в реализации конструктора типов полиморфизм.

Аналогичные расширения в языках, предназначенных для платформы .NET, более сложная задача, поскольку виртуальная машина имеет более богатое представление о типах и, таким образом, обеспечивает более строгие инварианты. К сожалению, модель типы не включают типы с более высоким родом. Таким образом, для обеспечения полного совместимость с универсальностью в других языках на этой платформе, компиляторы для языков с полиморфизмом конструктора типов должны прибегать частичное удаление, а также специализация кода для того, чтобы построить необходимые представления типов, которые являются результатом конструкторы абстрактных типов, применяемые к аргументам.

Вы можете просмотреть эту статью для объяснения того, почему дженерики с более высоким родом важны. Хотя Scala 2.8, по-видимому, не использует их широко в своей новой библиотеке коллекций, до сих пор я нахожу , невозможно реализовать мою библиотеку теории категорий подтипным элегантным способом без более высоких видов (в отличие от подтип дизайна, который я считаю чрезвычайно сложным).

Daniel C. Sobral относительно вашего комментария под вашим ответом, я думаю, что это принцип D в SOLID, который нарушается конструкторами. Городские Vagabon, фабрики должны быть использованы для достижения инверсии контроля, a / k / a Голливудский принцип. См. Также блог Гилада Брачи «Конструкторы считаются вредными».

Предполагается, что это не самый полный или лучший ответ, а некоторые частичные мысли, которые могут добавить к этой базе знаний.