Тип Haskell против нового типа в отношении безопасности типов

Основные области применения новых типов:

1. Для определения альтернативных экземпляров типов.
2. Документация.
3. Обеспечение правильности данных/формата.

Сейчас я работаю над приложением, в котором я широко использую новые типы. newtypes в Haskell — это чисто концепция времени компиляции. Например. с распаковщиками ниже, unFilename (Filename "x") скомпилирован в тот же код, что и "x". Существует абсолютно нулевое попадание во время выполнения. Есть с data типами. Это делает его очень хорошим способом достижения перечисленных выше целей.

-- | A file name (not a file path).
newtype Filename = Filename { unFilename :: String }
    deriving (Show,Eq)

Я не хочу случайно рассматривать это как путь к файлу. Это не путь к файлу. Это имя концептуального файла где-то в базе данных.

Для алгоритмов очень важно ссылаться на правильную вещь, в этом помогают новые типы. Это также очень важно для безопасности, например, рассмотрите возможность загрузки файлов в веб-приложение. У меня есть такие типы:

-- | A sanitized (safe) filename.
newtype SanitizedFilename = 
  SanitizedFilename { unSafe :: String } deriving Show

-- | Unique, sanitized filename.
newtype UniqueFilename =
  UniqueFilename { unUnique :: SanitizedFilename } deriving Show

-- | An uploaded file.
data File = File {
   file_name     :: String         -- ^ Uploaded file.
  ,file_location :: UniqueFilename -- ^ Saved location.
  ,file_type     :: String         -- ^ File type.
  } deriving (Show)

Предположим, у меня есть эта функция, которая очищает имя файла из загруженного файла:

-- | Sanitize a filename for saving to upload directory.
sanitizeFilename :: String            -- ^ Arbitrary filename.
                 -> SanitizedFilename -- ^ Sanitized filename.
sanitizeFilename = SanitizedFilename . filter ok where 
  ok c = isDigit c || isLetter c || elem c "-_."

Теперь из этого я создаю уникальное имя файла:

-- | Generate a unique filename.
uniqueFilename :: SanitizedFilename -- ^ Sanitized filename.
               -> IO UniqueFilename -- ^ Unique filename.

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

Но также может раздражать необходимость много обертывать/разворачивать. В долгосрочной перспективе я считаю, что это того стоит, особенно для предотвращения несоответствия значений. ViewPatterns немного помогают:

-- | Get the form fields for a form.
formFields :: ConferenceId -> Controller [Field]
formFields (unConferenceId -> cid) = getFields where
   ... code using cid ..

Может быть, вы скажете, что развернуть его в функции — это проблема — что, если вы неправильно передадите cid в функцию? Не проблема, все функции, использующие идентификатор конференции, будут использовать тип ConferenceId. Возникает что-то вроде системы контрактов между функциями, которая принудительно применяется во время компиляции. Довольно мило. Так что да, я использую его так часто, как могу, особенно в больших системах.

Я думаю, что это в большей степени зависит от ситуации.

Учитывайте пути. В стандартной прелюдии указано «type FilePath = String», потому что для удобства вы хотите иметь доступ ко всем операциям со строками и списками. Если бы у вас был «newtype FilePath = FilePath String», вам понадобился бы filePathLength, filePathMap и т. д., иначе вы навсегда использовали бы функции преобразования.

С другой стороны, рассмотрим SQL-запросы. SQL-инъекция — это обычная дыра в безопасности, поэтому имеет смысл иметь что-то вроде

newtype Query = Query String

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

Для простых объявлений X = Y type — это документация; newtype — проверка типов; вот почему newtype сравнивают с data.

Я довольно часто использую newtype именно для той цели, которую вы описываете: гарантировать, что что-то, что хранится (и часто манипулируется) таким же образом, как и другой тип, не будет перепутано с чем-то другим. Таким образом, это работает как немного более эффективное объявление data; нет особой причины предпочесть одно другому. Обратите внимание, что с расширением GHC GeneralizedNewtypeDeriving для любого из них вы можете автоматически получать классы, такие как Num, позволяя добавлять и вычитать ваши температуры или иены так же, как вы можете с Ints или чем-то еще, лежащим под ними. Однако с этим нужно быть немного осторожным; обычно нельзя умножать температуру на другую температуру!

Чтобы понять, как часто эти вещи используются, в одном довольно большом проекте, над которым я сейчас работаю, у меня около 122 применений data, 39 применений newtype и 96 применений type.

Но соотношение, что касается «простых» типов, немного ближе, чем это демонстрирует, потому что 32 из этих 96 применений type на самом деле являются псевдонимами для типов функций, таких как

type PlotDataGen t = PlotSeries t -> [String]

Здесь вы заметите две дополнительные сложности: во-первых, это фактически функциональный тип, а не просто псевдоним X = Y, а во-вторых, он параметризован: PlotDataGen — это конструктор типа, который я применяю к другому типу для создания нового типа, такого как PlotDataGen (Int,Double). . Когда вы начинаете делать такие вещи, type уже не просто документация, а фактически функция, хотя и на уровне типа, а не на уровне данных.

newtype иногда используется там, где type быть не может, например, когда необходимо определение рекурсивного типа, но я считаю, что это достаточно редко. Таким образом, похоже, по крайней мере, в этом конкретном проекте около 40% моих определений «примитивных» типов — это newtypes, а 60% — types. Некоторые из определений newtype раньше были типами и определенно были преобразованы именно по указанным вами причинам.

Короче говоря, да, это частая идиома.

Я думаю, что довольно часто используется newtype для различия типов. Во многих случаях это происходит потому, что вы хотите предоставить разные экземпляры классов типов или скрыть реализации, но просто желание защититься от случайных преобразований также является очевидной причиной для этого.