-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Build confusion #1
Comments
Okay, I'll look into sorting this out. I think one of the first steps is the unify the different parsers. Why are there more than one?! The question is whether to use Parsec (reasonable), or to use Matt's ParserLib. I'm leaning towards Parsec just because it's actively maintained and the cost of a Parsec dependency isn't too high. |
Hello, A bit of (ancient) history about this. The Parsec parser has been moribund since before I came to it when i was a masters student.. Basically Matt abandoned it at some point early on in F-Lite development, so if you're planning a move back to Parsec be aware that the language as supported in the Parsec parser may be different to a greater or lesser degree to the one supported by ParseLib. Likewise the Cabal build -- there's a shell script which is, to the best of my knowledge, the way Matt used to build. |
The Parsec parser does appear to have one advantage over the ParseLib parser: it handles infix addition, as ParseLib breaks on examples/Sum.hs:
|
So, my auto-par work is based on Marco's typechecker. I just looked now and the parsing magic is happening here: https://github.com/UoYCS-plasma/FliteDeprest/blob/master/Flite/Parsec/Parse.hs#L134 So, my vote is to go with this parser because a) it works with type declarations and b) seems to work with Michael's example. The additional question is should we just port to be using Parsec 3 the hackage library so that we don't have to maintain our own old fork? |
Yes, I think if we stick with Parsec, we should be using the official version. |
Oh dear, the Parsec parser doesn't support data declarations, as everything in the examples_types directory fails to parse. But the ParseLib parser doesn't handle every file in that directory either. Urgh. |
cabal configure -fpure
looks for anfl-pure.hs
file, as doesmake.sh
if there is nofl.hs
(which there is). I guess thatfl.hs
used to befl-pure.hs
.The result of this is that
cabal build
doesn't work if configured with thepure
flag, which means that regular oldcabal configure
needs to be used, which imposes a parsec dependency.However, the library can't be built without parsec anyway, as the type checker pulls it in, so either the pure flag should just be removed (and
make.sh
updated to reflect that), or the code should be updated to allow a build without parsec.The text was updated successfully, but these errors were encountered: