Partial Parsing? about copper HOT 15 CLOSED

from copper.

From what I remember, there's nothing on Copper's side here to do, unless you wanted something from the partially constructed tree stack. The way e.g. the eclipse-silver code works, it mutates a list of tokens during parsing, so you could just access them from the parser object after catching the parse error exception.

from copper.

Copper has no explicit support for partial parsing of erroneous input (although it is, of course, possible to accumulate a token list through the semantic actions).

from copper.

from copper.

The changes to Terminal present in the feature/ide and feature/monto+highlight branches of Silver already create make Terminal a superclass of all terminals, I think.

from copper.

from copper.

Maybe not a solution that'll be complete in a short time, but one solution would be to add what Rust calls trait objects to Silver. E.g. If I could write

synthesized attribute foo :: String;

traitishThing FooHaver(foo); -- I have the best words

function getFoo
String ::= fooTraitObject::FooHaver
{
  return "foo = " ++ fooTraitObject.foo;
}

and then any type with the foo attribute could be upcasted to the FooHaver type. I think these could be implemented as Java interfaces with minimal overhead.

We could then make TerminalDescriptor something like (startLoc, endLoc, lexeme, lexerClasses, grammarName, terminalName).

from copper.

This is properly a Silver issue at this point, I think.

We don't necessarily need anything fancy. I had hoped to have no general Terminal type in Silver at all, because I hoped it'd just be Java code that cared.

from copper.

from copper.

It's basically type classes, isn't it?

from copper.

from copper.

I'm going to try making an extension for silver that does Terminal -> TerminalDescriptor; sound good to everyone?

from copper.

from copper.

Does this look good for a TerminalDescriptor type?

from copper.

Talked with Eric, moving this to a Silver issue, will summarize there.

from copper.