Dan Debertin writes:
> My reason for asking is that parsing the entire language adds quite a
> bit of complexity to the grammar (upwards of 200 productions), not to
> mention a number of pesky S/R and R/R conflicts I have to chase down,
> for not much real gain AFAICT. If (like I did in CEDET's Ruby grammar)
> I could reduce it to just an infrastructure grammar it would simplify
> things quite a bit, but I will keep the full grammar if it would
> enable useful functionality.
A 'tagging grammar' is usually sufficient for most tasks. I could
imagine full grammars to be useful for things like refactoring or even
static code analysis, but really, no one has done that yet using
Semantic, so that's just me daydreaming.
> As I recently realized when I sat down to implement it, "smart
> completion" will probably never work with Scala. Since scala uses type
> inference, many variable and function types don't have to be declared
> at all in the code, so it's impossible (well, really hard) to know a
> variable's type until compile-time.
Yes, that's a hard problem. C++11 now has the same thing with the new
'auto' keyword. There's no easy way out; you have to look at the
right-hand side and infer the type. I think this will be possible for
C++, but I'm mostly afraid that it will make parsing much slower.
I've already looked at libclang, but this one has the problem of not
being fault-tolerant, which is problematic when parsing unfinished code.
> I am, per your advice, looking at the various overrides and
> determining what would be useful to implement, but with somewhat
> reduced enthusiasm.
Well, you got a chicken/egg problem here. You won't be able to properly
infer types as long as you don't have a working parser. Unfortunately, I
know nothing about Scala, so I can't really help you here or even tell
you how hard this might be. But you might be right that this is just not
feasible. Another approach might be to ask a compiler, like ENSIME does.
-David
|