Skip to content
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

Open
barrucadu opened this issue Mar 27, 2015 · 6 comments
Open

Build confusion #1

barrucadu opened this issue Mar 27, 2015 · 6 comments

Comments

@barrucadu
Copy link

cabal configure -fpure looks for an fl-pure.hs file, as does make.sh if there is no fl.hs (which there is). I guess that fl.hs used to be fl-pure.hs.

The result of this is that cabal build doesn't work if configured with the pure flag, which means that regular old cabal 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.

@jmct
Copy link
Member

jmct commented Mar 27, 2015

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.

@boxoffoxes
Copy link

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.

@barrucadu
Copy link
Author

The Parsec parser does appear to have one advantage over the ParseLib parser: it handles infix addition, as ParseLib breaks on examples/Sum.hs:

{

sumAcc acc Nil = acc;
sumAcc acc (Cons x xs) = sumAcc (acc+x) xs;

main = sumAcc 0 (Cons 1 (Cons 2 (Cons 3 Nil)))

}

@jmct
Copy link
Member

jmct commented Mar 28, 2015

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?

@barrucadu
Copy link
Author

Yes, I think if we stick with Parsec, we should be using the official version.

@barrucadu
Copy link
Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants