On Tue, Sep 14, 2010 at 12:22 PM, Thomas Schilling <nominolo@googlemail.com> wrote:
On 10 September 2010 13:57, JP Moresmau <jpmoresmau@gmail.com> wrote:
> Hello all,
> in EclipseFP I have tried to now use the GHC Lexer to provide syntax
> highlighting, and we use the GHC AST to provide the Eclipse view. However
> there are a couple of issues with this approach:
> - C preprocessing needs to be handled by ourselves since we don't want it to
> be applied

If you don't apply CPP some things might break.  For example if you
have two definitions of the same function and #ifdefs are used to
choose which one to use then ignoring CPP will lead to two
conflicting/incompatible definitions.

Yes, but in most cases it shouldn't be an issue for the Lexer, which is what I need for syntax highlighting. And for the outline view, if the same function appears twice we can live with that.

 
> - Line pragmas mean lexer tokens have a location that doesn't correspond to
> the actual source file (possibly crashing the Eclipse editor) and that
> outline components do not point to the proper location in the source file

I know that literate Haskell preprocessing often leads to incorrect
positions (off by two columns) and that some preprocessors create
incorrect line pragmas.  However, in general I think you want to
interpret line pragmas so that the error is shown in the actual source
file and not some intermediate file.


I don't care about compilation errors, it's fine if they are reported in the original source. I care about the lexer tokens so I can syntax highlight the generated file. I develop an IDE, not a compiler. I think users have the right to open the files they want.
 
> - Outline is not visible when the module doesn't typecheck

That's a harder problem.  There are two failure modes:

 1. The file doesn't parse (e.g., forgot a closing ")").  This usually
leads to utterly useless error messages from GHC.  My tentative
solution for this problem is to use a rough "outline parser" that
tries to figure out the end of definitions and then use this to skip
some chunks.

 2. The file doesn't rename+typecheck.  If the file doesn't typecheck
but renaming succeeds the GHC API currently doesn't give us back the
renamed code.  You could use the error message locations to cut out
parts of the parse tree (and replace them by "undefined") until it
renames/typechecks.  If you're only interested in the outline view the
parse tree should be fine, though.  I'm not sure adding yet another
syntax tree type via haskell-src-exts would be such a good idea.


Well haskell-src-exts give us a parse tree even if typechecking fails, and an option to disable Line pragmas handling when we don't want them. I need it for two methods in Scion (outline and tokenTypes) so as long as the API doesn't move I don't really care how it's implemented underneath. It seems to me adding haskell-src-exts is easier than having to cut the source code into tasty little bits to work around typechecking errors... That's what I do now: I replace CPP and Line pragmas by blank lines before I call the GHC Lexer. Tedious, error prone, I have better things to do than write another buggy preprocessor, and it doesn't work for outline that needs the parse tree. 
 
>
> I was then thinking about alternatives. A good solution would be maybe
> haskell-src-exts. It exposes an option to ignore line pragmas, the parse
> result type derives from Data which would allow for generic traversal. I was
> wondering if anybody here could share any experience with that library, or
> think of reasons not to use that from within Scion (reminder: the version of
> Scion we use inside EclipseFP is not the published one, which is maybe
> unfortunate but allows me to modify Scion for the EclipseFP needs without
> worrying too much about compatibility).
> Cheers,
> --
> JP Moresmau
> http://jpmoresmau.blogspot.com/
>
> --
> You received this message because you are subscribed to the Google Groups
> "scion-lib-devel" group.
> To post to this group, send email to scion-lib-devel@googlegroups.com.
> To unsubscribe from this group, send email to
> scion-lib-devel+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/scion-lib-devel?hl=en.
>



--
If it looks like a duck, and quacks like a duck, we have at least to
consider the possibility that we have a small aquatic bird of the
family Anatidae on our hands.

--
You received this message because you are subscribed to the Google Groups "scion-lib-devel" group.
To post to this group, send email to scion-lib-devel@googlegroups.com.
To unsubscribe from this group, send email to scion-lib-devel+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/scion-lib-devel?hl=en.




--
JP Moresmau
http://jpmoresmau.blogspot.com/