haskell中String和Data.Text之间的自动转换

时间:2014-03-25 17:17:34

标签: string haskell type-conversion

正如Nikita Volkov在他的问题Data.Text vs String中提到的,我也想知道为什么我必须处理haskell中的不同String实现type String = [Char]Data.Text。在我的代码中,我经常使用packunpack函数。

我的问题:有没有办法在两种字符串类型之间进行自动转换,这样我就可以避免经常写packunpack

在其他编程语言(如Python或JavaScript)中,例如,如果需要,可以在整数和浮点数之间进行自动转换。我可以在haskell中达到类似的效果吗?我知道,所提到的语言是弱类型的,但我听说C ++有类似的功能。

注意:我已经知道语言扩展名{-# LANGUAGE OverloadedStrings #-}。但据我所知,这种语言扩展仅适用于定义为"..."的字符串。我希望自动转换字符串,这是我从其他函数获得的,或者我在函数定义中作为参数。

扩展问题: Haskell. Text or Bytestring还涵盖了Data.TextData.ByteString之间的区别。有没有办法在三个字符串StringData.TextData.ByteString之间进行自动转换?

2 个答案:

答案 0 :(得分:29)

没有

Haskell并没有因技术,哲学和宗教原因而进行隐式强制。

作为评论,在这些表示之间进行转换并非免费,并且大多数人都不喜欢您隐藏的潜在昂贵计算的想法。此外,将字符串作为惰性列表,将它们强制转换为Text值可能不会终止。

我们可以使用Text自动将文字转换为OverloadedString s,将"foo"字符串为fromString "foo" fromString Text pack只需拨打unpack

问题可能是问你为什么这么强迫?您是否经常需要Text {{1}}值?如果你不断地将它们改成字符串,它就会失去目的。

答案 1 :(得分:29)

几乎是:Data.String.Conversions

Haskell库使用不同的类型,因此在很多情况下除了大量使用转换之外别无选择,反之亦然 - 重写库并不算作真正的选择。

我看到两个具体的问题,其中任何一个都可能成为Haskell采用的重大问题:

  • 编码最终需要您想要使用的库的特定实现知识。这是高级语言的一个大问题

  • 简单任务的表现很差 - 通才语言的big issue

从特定类型中提取

根据我的经验,第一个问题是猜测包名称在基本上对相同数据进行操作的库之间保持正确功能的时间。

问题有一个非常方便的解决方案:Data.String.Conversions package,前提是您对UTF-8作为默认编码感到满意。

此软件包在多种不同类型之间提供单个cs转换功能。

  • String
  • Data.ByteString.ByteString
  • Data.ByteString.Lazy.ByteString
  • Data.Text.Text
  • Data.Text.Lazy.Text

所以你只需要import Data.String.Conversions,然后使用cs根据输入和输出类型推断出正确的转换函数版本。

示例:

import Data.Aeson              (decode)
import Data.Text               (Text)
import Data.ByteString.Lazy    (ByteString)
import Data.String.Conversions (cs)

decodeTextStoredJson' :: T.Text -> MyStructure
decodeTextStoredJson' x = decode (cs x) :: Maybe MyStructure

注意:在GHCi中,您通常没有提供目标类型的上下文,因此您可以通过明确说明结果的类型来指导转换,例如read

let z = cs x :: ByteString

表现和对#34; true"溶液

我还没有意识到任何真正的解决方案 - 但我们已经可以猜出方向了

  • 要求转换是合法的,因为数据不会改变;
  • 出于管理目的,将数据从一种类型转换为另一种类型,从而实现最佳性能;
  • 胁迫是邪恶的 - 甚至是强制的。

因此,方向必须是使这些类型没有区别,即在它们全部派生的一个archtype之下(或之上)协调它们,允许使用不同的派生来组合函数,而不需要转换。

Nota:我绝对无法评估这个想法的可行性/潜在缺点。可能有一些非常好的塞子。