Integration of dhall #72
Conversation
…ble dhases (like in cassava)
| component = P.munch1 (\c -> isAlphaNum c || c `elem` "_") | ||
| parsec' = (:) <$> lead <*> rest | ||
| lead = P.satisfy (\c -> isAlphaNum c || c == '_') | ||
| rest = P.munch (\c -> isAlphaNum c || c == '_' || c == '-') |
There was a problem hiding this comment.
Do these changes change the parsing behavior or is it just a refactoring?
There was a problem hiding this comment.
It is weird but testing with .cabal files gave me an error when indexing cassava with PARSEC option. It has an infamous flag with an internal double dash. Dont know why previous etlas version that has PARSEC enabled didnt throw the error
(See 1847005)
There was a problem hiding this comment.
This is a weird thing in that stack.yaml in this repo turns on the parsec flag, while the stack.yaml in the main eta repo doesn't. So the etlas you use normally when doing ./cleaninstall.sh doesn't use parsec.
There was a problem hiding this comment.
Ohhh, ok, however i think i've used etlas installed from its own repo and i dont remember having that error (cassava is always indexed?).. anyway afaik the new flag parser is more robust cause it will support previous and future flag formats
| Nothing -> error $ "Couldn't read cabal file " | ||
| ++ show fileName | ||
| parsed = if takeExtension fileName == ".dhall" | ||
| then fmap Just $ PackageDesc.Parse.parseGenericPackageDescriptionFromDhall fileName |
There was a problem hiding this comment.
Does parsing dhall files always succeed?
There was a problem hiding this comment.
Nvm this is parsing from the index, so only valid dhall files will be parsed.
See #66 (comment)