Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Archived » IMP » Parser message adaptation/customization
Parser message adaptation/customization [message #25297] Fri, 07 November 2008 22:50 Go to next message
Robert M. Fuhrer is currently offline Robert M. FuhrerFriend
Messages: 294
Registered: July 2009
Senior Member
Hi All,

It's recently come to light that some of our users don't like the
messages coming out of the parsers they're using, and they would
thus like to customize the messages (e.g. to make them more human-
consumable) without changing the parser itself.

IMP presently defines an IMessageHandler interface that it passes
into the IParseController so that the IParseController has a place
to which to direct messages coming out of the parser.

So, it's presently possible to customize parser messages by changing
the IParseController (or whatever actually passes messages to the
IMessageHandler) to modify the messages before handing them upward.

That said, at least when using LPG and the SimpleLPGParseController,
the spot to customize is buried in the class MessageHandlerAdapter,
which adapts the LPG-defined message handling interface (sadly also
called IMessageHandler) to whatever implements the IMP-defined
IMessageHandler interface. So one would have to replace the
MessageHandlerAdapter with something that does the appropriate
message fiddling, and instantiate that in your IParseController's
override of parse().

So our question to you, dear Reader, if you're not already blind
at this point, is:

Is this arrangement complicated enough that we ought to provide a
more direct and obvious way to customize parser messages?

--
Cheers,
-- Bob

--------------------------------
Robert M. Fuhrer
Research Staff Member
Programming Technologies Dept.
IBM T.J. Watson Research Center

IDE Meta-tooling Platform Project Lead (http://www.eclipse.org/imp)
X10: Productive High-Performance Parallel Programming (http://x10.sf.net)
Re: Parser message adaptation/customization [message #25457 is a reply to message #25297] Wed, 12 November 2008 20:37 Go to previous messageGo to next message
Stan Sutton is currently offline Stan SuttonFriend
Messages: 121
Registered: July 2009
Senior Member
I think there are really two questions implicit in the one question that
Bob asks at the end of his posting.

One is, should we provide some support for customizing parser messages,
regardless of the parser technology used?

The other is, should we provide a more convenient way to customize
parser messages from an LPG parser as used with our standard
SimpleLPGParseController?

I'm inclined to answer "yes" to both questions.

In both cases, the IDE developer can customize messages by developing or
modifying the parse controller implementation, but in either case that
may be more work than the developer really wants to undertake. So it
would be good if we could provide some help.

Since we want to facilitate the use of LPG, I think it makes sense for
us to facilitate the customization of messages from LPG-generated
parsers. To do this, we can leverage the other components that we
supply for use with LPG, such as the MessageHandlerAdapter and the
SimpleLPGParseController (or the language-specific extensions that we
generate for it).

But we don't want to restrict IMP users to use LPG, so it would also be
nice to have some avenue to customization of messages from any parser
(or for alternative implementations for the parse controller).
Customization approaches that are geared for use with LPG may not work
well for other parser technologies.

There are probably some additional questions lurking in here, but I'm
going to leave it at that for now.

Bob and I have discussed this without coming to any conclusion, and we'd
really like to get some other perspectives!

Thanks,

Stan Sutton




Robert M. Fuhrer wrote:
> Hi All,
>
> It's recently come to light that some of our users don't like the
> messages coming out of the parsers they're using, and they would
> thus like to customize the messages (e.g. to make them more human-
> consumable) without changing the parser itself.
>
> IMP presently defines an IMessageHandler interface that it passes
> into the IParseController so that the IParseController has a place
> to which to direct messages coming out of the parser.
>
> So, it's presently possible to customize parser messages by changing
> the IParseController (or whatever actually passes messages to the
> IMessageHandler) to modify the messages before handing them upward.
>
> That said, at least when using LPG and the SimpleLPGParseController,
> the spot to customize is buried in the class MessageHandlerAdapter,
> which adapts the LPG-defined message handling interface (sadly also
> called IMessageHandler) to whatever implements the IMP-defined
> IMessageHandler interface. So one would have to replace the
> MessageHandlerAdapter with something that does the appropriate
> message fiddling, and instantiate that in your IParseController's
> override of parse().
>
> So our question to you, dear Reader, if you're not already blind
> at this point, is:
>
> Is this arrangement complicated enough that we ought to provide a
> more direct and obvious way to customize parser messages?
>
Re: Parser message adaptation/customization [message #25882 is a reply to message #25457] Tue, 25 November 2008 06:59 Go to previous message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
> One is, should we provide some support for customizing parser messages,
> regardless of the parser technology used?
>
> The other is, should we provide a more convenient way to customize
> parser messages from an LPG parser as used with our standard
> SimpleLPGParseController?
>
> I'm inclined to answer "yes" to both questions.

Yes. But the solution should be neutral.

The current code is complicated by the large amount of variantly
formatted data that is passed around. These are passed as parameters and
so there are numerous inconsistent and inadequate short parameter lists.

formatted message
message template + message arguments
message number
resource/file
severity
originating context
processing phase
startToken + endToken
startOffset + endOffset
startCol + endCol
startLine + endLine
.... custom concepts

There are also many different audiences for messages:
- hover annotations
- ruler annotations
- marker overviews
- marker properties
- log files
- unit tests
- quick fixes

And of course internationalisation.

Might I suggest introduction of an IMessageDescriptor interface to
mediate between producer and consumer. The IMessageDescriptor should
capture the message so that either java.text.MessageFormat.format or
org.eclipse.osgi.util.NLS.bind is used to format the message. The
particular variant of IToken should be kept out of the main interface;
an LPG2 IToken can be introduced by a concrete LPG2MessageDescriptor.

With the message carried by an IMessageDescriptor, consumer code can
format as appropriate for presentation. Producer code can be simplified
by creating the IMessageDescriptor before context is lost by passing
through a daisy chain of restrictive argument lists.

Arbitrary customisation can be achieved by a mapping of originator's
message-format-template/error-code to a better-message-template.

Use of existing parsers could perhaps be assisted by a message unparser,
but at least in LPG it's probably easier to intercept calls earlier. For
new grammars the message descriptors should be generated directly.

Regards

Ed Willink
Re: Parser message adaptation/customization [message #574148 is a reply to message #25297] Wed, 12 November 2008 20:37 Go to previous message
Stan Sutton is currently offline Stan SuttonFriend
Messages: 121
Registered: July 2009
Senior Member
I think there are really two questions implicit in the one question that
Bob asks at the end of his posting.

One is, should we provide some support for customizing parser messages,
regardless of the parser technology used?

The other is, should we provide a more convenient way to customize
parser messages from an LPG parser as used with our standard
SimpleLPGParseController?

I'm inclined to answer "yes" to both questions.

In both cases, the IDE developer can customize messages by developing or
modifying the parse controller implementation, but in either case that
may be more work than the developer really wants to undertake. So it
would be good if we could provide some help.

Since we want to facilitate the use of LPG, I think it makes sense for
us to facilitate the customization of messages from LPG-generated
parsers. To do this, we can leverage the other components that we
supply for use with LPG, such as the MessageHandlerAdapter and the
SimpleLPGParseController (or the language-specific extensions that we
generate for it).

But we don't want to restrict IMP users to use LPG, so it would also be
nice to have some avenue to customization of messages from any parser
(or for alternative implementations for the parse controller).
Customization approaches that are geared for use with LPG may not work
well for other parser technologies.

There are probably some additional questions lurking in here, but I'm
going to leave it at that for now.

Bob and I have discussed this without coming to any conclusion, and we'd
really like to get some other perspectives!

Thanks,

Stan Sutton




Robert M. Fuhrer wrote:
> Hi All,
>
> It's recently come to light that some of our users don't like the
> messages coming out of the parsers they're using, and they would
> thus like to customize the messages (e.g. to make them more human-
> consumable) without changing the parser itself.
>
> IMP presently defines an IMessageHandler interface that it passes
> into the IParseController so that the IParseController has a place
> to which to direct messages coming out of the parser.
>
> So, it's presently possible to customize parser messages by changing
> the IParseController (or whatever actually passes messages to the
> IMessageHandler) to modify the messages before handing them upward.
>
> That said, at least when using LPG and the SimpleLPGParseController,
> the spot to customize is buried in the class MessageHandlerAdapter,
> which adapts the LPG-defined message handling interface (sadly also
> called IMessageHandler) to whatever implements the IMP-defined
> IMessageHandler interface. So one would have to replace the
> MessageHandlerAdapter with something that does the appropriate
> message fiddling, and instantiate that in your IParseController's
> override of parse().
>
> So our question to you, dear Reader, if you're not already blind
> at this point, is:
>
> Is this arrangement complicated enough that we ought to provide a
> more direct and obvious way to customize parser messages?
>
Re: Parser message adaptation/customization [message #574528 is a reply to message #25457] Tue, 25 November 2008 06:59 Go to previous message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
> One is, should we provide some support for customizing parser messages,
> regardless of the parser technology used?
>
> The other is, should we provide a more convenient way to customize
> parser messages from an LPG parser as used with our standard
> SimpleLPGParseController?
>
> I'm inclined to answer "yes" to both questions.

Yes. But the solution should be neutral.

The current code is complicated by the large amount of variantly
formatted data that is passed around. These are passed as parameters and
so there are numerous inconsistent and inadequate short parameter lists.

formatted message
message template + message arguments
message number
resource/file
severity
originating context
processing phase
startToken + endToken
startOffset + endOffset
startCol + endCol
startLine + endLine
.... custom concepts

There are also many different audiences for messages:
- hover annotations
- ruler annotations
- marker overviews
- marker properties
- log files
- unit tests
- quick fixes

And of course internationalisation.

Might I suggest introduction of an IMessageDescriptor interface to
mediate between producer and consumer. The IMessageDescriptor should
capture the message so that either java.text.MessageFormat.format or
org.eclipse.osgi.util.NLS.bind is used to format the message. The
particular variant of IToken should be kept out of the main interface;
an LPG2 IToken can be introduced by a concrete LPG2MessageDescriptor.

With the message carried by an IMessageDescriptor, consumer code can
format as appropriate for presentation. Producer code can be simplified
by creating the IMessageDescriptor before context is lost by passing
through a daisy chain of restrictive argument lists.

Arbitrary customisation can be achieved by a mapping of originator's
message-format-template/error-code to a better-message-template.

Use of existing parsers could perhaps be assisted by a message unparser,
but at least in LPG it's probably easier to intercept calls earlier. For
new grammars the message descriptors should be generated directly.

Regards

Ed Willink
Previous Topic:LPG question: how to add a method to generated code
Next Topic:New annotation creation service?
Goto Forum:
  


Current Time: Fri Mar 29 12:48:22 GMT 2024

Powered by FUDForum. Page generated in 0.02577 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top