Most parser libraries in Haskell provide facilities for including source
information.
And then you include in your syntax tree extra fields for those positions.
Simple as that
The paper :
http://david.darais.com/assets/papers/abstracting-definitional-interpreters/...
Is a great reference for how to add a bunch of program analysis features
after you have a working interpreter . Also it’s citations show a bunch of
ways you can Add different flavored of anayses
On Mon, Nov 26, 2018 at 3:37 PM Olaf Klinke
Hello Olaf,
to me that sounds as if you want to do an abstract interpretation with a forward collecting semantics that employs non-relational abstract domains for the primitive data types and summarizes the dimensions of arrays. ... I would start by writing a simple interpreter for the language to be analyzed. That way you fix messy details before they bite you, e.g. the order in which submodules are loaded and initialized.
I was hoping not having to write an interpreter (because the language author wrote a translation to C++ already), but if that is the way to go, I'll do it. As I understand it, the Haskell semantics should contain just enough substance so that the errors I am after will cause hiccups in the Haskell compiler? That is indeed a compelling approach. What this does not address is the question about error reporting: How could a translation to Haskell preserve information about scope, source position and masking? Can I leverage the ghc API for that?
Regards, Olaf _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.