blaze-html, Haskell, правильное использование toHtml?

Question

Две вещи, которые я не могу понять: 1) Без {-# LANGUAGE OverloadedStrings #-} ни один типичный код, где чистые строки передаются в качестве аргументов для атрибутов, не работает; Однако все хорошо, пока эта инструкция есть. Что он делает в данном конкретном случае и насколько безопасно его использовать в рабочем коде?

2) Следующий фрагмент кода: (toHtml $ "<script ... ></script>") терпит неудачу с чем-то, чего я не совсем понимаю:

Неопределенная переменная типа "a0", возникающая из литерала ... предотвращает решение ограничения (Data.String.IsString a0). Возможное исправление: используйте аннотацию типа, чтобы указать, каким должен быть «a0». Эти потенциальные случаи существуют: экземпляр Data.String.IsString H.AttributeValue - определен в «blaze-markup-0.8.2.1: Text.Blaze.Internal» экземпляр Data.String.IsString H.Tag - определен в «blaze-markup-0.8.2.1: Text.Blaze.Internal» экземпляр ~ Char => Data.String.IsString [a] - определен в ‘Data.String’ ... плюс 10 экземпляров, включающих типы вне области действия

Answer 1

1. В стандартном Haskell строковый литерал, такой как "foo", всегда разбирается в значение типа String = [Char]. Blaze не использует фактические значения String в большинстве мест, вместо этого использует свои собственные типы, такие как AttributeValue для каждой семантически разных вещей. Это означает, что в стандартном Haskell без OverloadedStrings невозможно передать строковые литералы многим функциям Blaze, которые ожидают AttributeValue s, Tag s и т. Д. Когда вы установите -XOverloadedStrings, GHC разрешит строковый литерал иметь тип Data.String.IsString p => p вместо String, так что вы можете использовать строковый литерал везде, где ожидается некоторый тип с экземпляром IsString. Это используется всем «стандартным» кодом Blaze. OverloadedStrings - довольно простое расширение - оно в основном делает для строковых литералов то, что Num делает для целочисленных литералов - и я не знаю о каких-либо больших противоречиях вокруг него. Я думаю, что он должен быть безопасным для использования в производственном коде, и несколько производственных кодовых баз используют его.

2. Это сообщение об ошибке связано с тем, что toHtml определяется количественно по типу его первого аргумента с некоторыми ограничениями: toHtml :: ToMarkup a => a -> Html и --- с OverloadedStrings --- типом строки также является переменной типа. По сути, GHC знает, что тип строкового литерала, который будет передан в toHtml, должен быть некоторого типа, и этот тип должен иметь экземпляры для ToMarkup и IsString, но он не имеет никакого способа чтобы быть уверенным, что этот тип должен быть! В этом случае, похоже, что вы, вероятно, ищете строковый литерал, который на самом деле имеет тип String, который можно получить, вручную пометив литерал: toHtml ("foo" :: String) или используя -XTypeApplications: toHtml @String "foo".