In my project migratum I wanted to enforce a naming convention like this
V<version number>__<file name>.sql + + + + + + | | | | | | | | | | | v | | | | | Enforce sql extension. | | | | v | | | | Enforce this dot to indicate the end of the file name. | | | v | | | File name need to be alpha numeric. No other symbols, except underscore | | v | | Enforce the double underscore | v | Version number have to be numbers. v Enforce the V character to signify "version" Ways I can accomplish these are with
- Regex
- Parser Combinators
I'm not sure how to do this with regex because to be honest, I know very simple regex and I don't have a regex license. I'm decent with parser combinators and plus it's the title of this blog post, so that's what I'm going to use to accomplish the task I set out for.
Parser combinators really shine when you parse something recursive like json. You know how json can contain an array and objects and then these objects and arrays can contain arrays and objects, so on and so forth? Yeah, parser combinators are really neat for that. So don't judge parser combinators solely on this blog post. I chose parser combinators because it's my go-to method for parsing, and I personally think they're convenient.
Before we touch parsing, let's create a type representation of the file name based on the ascii diagram above.
data FilenameStructure = FilenameStructure FileVersion Underscore Underscore FileName Dot FileExtension deriving ( Eq, Show ) newtype FileVersion = FileVersion Text deriving ( Eq, Show ) newtype Underscore = Underscore Text deriving ( Eq, Show ) newtype FileName = FileName Text deriving ( Eq, Show ) newtype Dot = Dot Text deriving ( Eq, Show ) newtype FileExtension = FileExtension Text deriving ( Eq, Show ) Now, we can focus on specific segments of the file name instead of thinking of parsing the entire file name. I think that makes it a bit easier. At least to me it does. I can think of parsing the file version, underscore, filename, etc individually.
Let's start with the imports. Popular libraries that come to mind are parsec, megaparsec, and attoparsec. Evaluate which one suits your project, but on this blog post we're using parsec.
-- parsec import Text.ParserCombinators.Parsec (GenParser, ParseError) import qualified Text.ParserCombinators.Parsec as Parsec -- text import qualified Data.Text as T Let's start with the file version parser. Our convention says that we need to start with the character V, then it should be followed by numbers.
fileVersionParser :: GenParser Char st FileVersion fileVersionParser = do vChar <- Parsec.char 'V' vNum <- Parsec.digit pure $ FileVersion $ T.pack $ ( vChar : vNum : [] ) If we try this in ghci it will look like this
ghci> import Text.ParserCombinators.Parsec ghci> parse fileVersionParser "" "V69" ghci> Right ( FileVersion "V69" ) That's what we want, to match Right and return our FileVersion with
the text "V69".
ghci> parse fileVersionParser "" "Vwhat" ghci> Left (line 1, column2): unexpected "w" That's right, it should fail when there's no version number.
ghci> parse fileVersionParser "" "V1what" ghci> Right ( FileVersion "V1" ) It drops the input that isn't a number.
ghci> parse fileVersionParser "" "what" ghci> Left (line 1, column 1): unexpected "w" expecting "V" Finally, it will fail if it doesn't find the "V" character.
Woohoo! One parser down, four to go!
Let's do the rest of the parsers, and feel free to try these out in ghci.
underscoreParser :: GenParser Char st Underscore underscoreParser = Underscore . T.pack . pure <$> Parsec.satisfy isUnderscore isUnderscore :: Char -> Bool isUnderscore char = any ( char== ) ( "_" :: String ) fileNameParser :: GenParser Char st FileName fileNameParser = FileName . T.pack <$> Parsec.many ( Parsec.alphaNum <|> Parsec.satisfy isUnderscore ) dotParser :: GenParser Char st Dot dotParser = Dot . T.pack . pure <$> Parser.char '.' fileExtensionParser :: GenParser Char st FileExtension fileExtensionParser = FileExtension. T.pack <$> Parsec.string "sql" Then, to create a parser for the whole file name we combine the rest of our parsers.
filenameStructureParser :: GenParser Char st FilenameStructure filenameStructureParser = FilenameStructure <$> fileVersionParser <*> underscoreParser <*> underscoreParser <*> fileNameParser <*> dotParser <*> fileExtensionParser We can also do this with the do syntax if that's more convenient.
filenameStructureParser :: GenParser Char st FilenameStructure filenameStructureParser = do version <- fileVersionParser u1 <- underscoreParser u2 <- underscoreParser fileName <- fileNameParser dot <- dotParser ext <- fileExtensionParser pure $ FilenameStructure version u1 u2 fileName dot ext Finally, our parser "runner"
namingConvention :: String -> Either ParseError FilenameStructure namingConvention = Parsec.parse filenameStructureParser "Error: Not following naming convention" Instead of manually trying them out in ghci we can instead do some unit testing. So we don't have to keep messing with the terminal.
module NamingConventionSpec where import Test.Hspec spec :: Spec spec = do desribe "Filename" $ do it "follows naming convention" $ do successResult <- pure $ namingConvention "V1__uuid_extension.sql" emptyFileName <- pure $ namingConvention "" noExtension <- pure $ namingConvention "V1__uuid_extension" noVersion <- pure $ namingConvention "uuid_extension.sql" upperCaseFileName <- pure $ namingConvention "V1_UUID_extension.sql" symbolFileName <- pure $ namingConvention "V1_UUID+extension.sql" -- success cases shouldBe successResult ( Right "V1__uuid_extension.sql" ) shouldBe upperCaseFileName ( Right "V1__UUID_extension.sql" ) -- failure cases shouldBe ( isLeft emptyFileName ) True shouldBe ( isLeft noFileExt ) True shouldBe ( isLeft noVersion ) True shouldBe ( isLeft symbolFilename ) True Now that we have our parser we can use it check for duplicates, because our types have an Eq instance we can do equality checking.
fileVersion :: FilenameStructure -> FileVersion fileVersion ( FilenameStructure v _ _ _ _ _ ) = v getVersion :: Either ParseError FilenameStructure -> Either ParseError FileVersion getVersion res = case res of Left err -> Left err Right fs -> Right $ fileVersion fs checkDuplicate :: [ String ] -> Either ParseError [ String ] checkDuplicate filenames = do versions <- traverse getVersion ( namingConvention <$> filenames ) if anySame versions -- Express your errors however you want, this is just to show that this is -- the error branch. then error "Duplicate migration file" else Right filenames where anySame :: Eq a => [ a ] -> Bool anySame = isSeen [] isSeen :: Eq a => [ a ] -> [ a ] -> Bool isSeen seen ( x:xs ) = x `elem` seen || isSeen ( x:seen ) xs isSeen _ [] = False When creating your parsers, avoid doing any validation or any "smart" logic. Concentrate on parsing the input and nothing more. Once you have your parsers then you can do whatever you want with the output.
Top comments (2)
Excellent!
This is actually a good use-case for regular expressions. In Haskell you have regex-applicative which is also a parser combinator library, except it is not monadic, and for that reason is restricted to regular languages.
Here is how a parser might look like:
And here it is in action:
For comparison, this is how it might look with Megaparsec:
And in action you see one benefit of using Megaparsec over Parsec or regex-applicative: Superior error messages.
The error messages could be improved significantly by simply altering the
”version”and”filename”hints in the source code, e.g. by specifying in human-readable terms what a filename is, and what a version is. Parsec does have the<?>operator, too, but Parsec does not provide this very graphical demonstration of where parsing went wrong, it only reports the label itself, and, IIRC, the Char offset in the input String!Another advantage of Megaparsec is native
Textsupport; I don't find that it's particularly useful in this usecase, sinceFilePathis aliased toString.