高效文件处理
默认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 模块的文档中找到。
