Usando Parsec 3.1
, es posible analizar varios tipos de entradas:Parsec con data.text
[Char]
conText.Parsec.String
Data.ByteString
conText.Parsec.ByteString
Data.ByteString.Lazy
conText.Parsec.ByteString.Lazy
I no veo nada para el módulo Data.Text
. Quiero analizar el contenido de Unicode sin sufrir las ineficiencias String
. Por lo tanto, hemos creado el siguiente módulo basado en el módulo Text.Parsec.ByteString
:
{-# LANGUAGE FlexibleInstances, MultiParamTypeClasses #-}
{-# OPTIONS_GHC -fno-warn-orphans #-}
module Text.Parsec.Text
(Parser, GenParser
) where
import Text.Parsec.Prim
import qualified Data.Text as T
instance (Monad m) => Stream T.Text m Char where
uncons = return . T.uncons
type Parser = Parsec T.Text()
type GenParser t st = Parsec T.Text st
- ¿Tiene sentido hacerlo?
- ¿Es esto compatible con el resto de API de Parsec?
Comentarios adicionales:
he tenido que añadir {-# LANGUAGE NoMonomorphismRestriction #-}
pragma en mis módulos de análisis sintáctico para hacer que funcione.
El análisis Text
es una cosa, la construcción de un AST con Text
es otra cosa. También necesitaré a mi pack
String
antes del regreso:
module TestText where
import Data.Text as T
import Text.Parsec
import Text.Parsec.Prim
import Text.Parsec.Text
input = T.pack "xxxxxxxxxxxxxxyyyyxxxxxxxxxp"
parser = do
x1 <- many1 (char 'x')
y <- many1 (char 'y')
x2 <- many1 (char 'x')
return (T.pack x1, T.pack y, T.pack x2)
test = runParser parser() "test" input
Está funcionando bien excepto por los módulos 'Text.Parsec.Language' y' Text.Parsec.Token' que están restringidos a 'String'. Puedo solucionar ese problema ejecutando mi propia tokenización. 'Text.Parsec.Language' es solo un gadget de todos modos (¿Mondrian? ¿Alguien?). – gawi
¡Ah! Me pregunto si podemos generalizar esos a cualquier secuencia de Char de una manera compatible hacia atrás. No parece difícil, pero como nunca uso esos módulos, no tengo ningún buen caso de prueba. –