《Real World Haskell》笔记（8）：文件处理、正

高效文件处理

默认String类型为何效率不高？

• String 是元素类型为 Char 的列表，列表每个元素被单独分配内存，有一定写入开销
• 对需要读取文本及二进制数据的程序来说，内存消耗和执行效率会受到较大影响

ByteString库为提高效率提供作为String替代物的两个模块，

• Data.ByteString 定义 ByteString 的严格类型
  利用数组表示字符串、二进制数据或文本，适用于不在意内存占用而且需要随机访问的数据。
• Data.ByteString.Lazy 定义 ByteString 的惰性类型
  将字符串表示为由块组成的列表，每个块是大小为 64KB 的数组，适用于大体积的文件流。

限定载入

--file elf.hs
import qualified Data.ByteString.Lazy as L
hasElf::L.ByteString->Bool
hasElf content=L.take 4 content == elfMagic
    where elfMagic = L.pack [0x7f, 0x45, 0x4c, 0x46]

• 限定载入语法import qualified ... as ... 把模块关联到另一个选定的名字
  若要使用该被限定载入模块中的函数，需要用选定的名字前缀 如L.take，限定载入可以防止不同模块函数重名。
• 无论是否使用有限载入，始终可以使用模块全名来引用函数

Haskell正则表达式

Haskell正则表达式需要使用Text.Regex.Posix模块，通常需要stack install regex-posix安装该模块才可以使用。以中缀运算符 =~表示的正则表达式匹配函数是该模块中较重要的函数。
(=~) :: (RegexMaker Regex CompOption ExecOption source, RegexContext Regex source1 target) => source1 -> source -> target，由于其返回类型多态，

• 在ghci中使用该函数时，需要指定希望获取结果的类型，如"my left foot" =~ "foo" :: Bool，否则 ghci 将因无法获得足够信息对匹配结果进行类型推导而报错
• 在实际编码中使用该函数时，ghc通过我们如何使用匹配结果推导出它的类型
• 第一个参数 (=~左侧) 是要被匹配的文本，第二个参数 (=~ 右侧) 是准备匹配的正则表达式，对每个参数我们都可以使用 String 或者 ByteString，可以将模式串定义为变量 let pat = "(foo[a-z]*bar|quux)"

库内部所含类型类RegexContext，该类型类描述目标类型的行为

• 目标类型为 Bool ，作为该类型类的实例，描述是否取回可用的结果
• 目标类型为 Int ， 作为该类型类的实例，描述正则表达式匹配的次数
• 目标类型为 String，获取第一个匹配的子串，或者表示无匹配的空字符串
• 目标类型为 [[String]]，获取由所有匹配的字符串组成的列表
• 结果类型为(String,String,String) 的三元组，三个元素分别获取字符串中首次匹配之前的部分，首次匹配的子串，和首次匹配之后的部分
• 结果类型为(String,String,String,[String])的四元组，元组的第四个元素是一个包含所有成功匹配子串的列表
• 结果类型为(Int,Int)的二元组，获取首次匹配在字符串中的偏移，以及匹配结果的长度；首个元素值为 -1 时，匹配失败。
• 结果类型为[(Int,Int)]的二元组列表，获取所有成功匹配子串的此类信息；当指定返回值为列表时，空表表示失败。
• RegexContext 类型类内置实例的完整清单在 Text.Regex.Base.Context 模块的文档中找到。