Subject: RE: [rohc] RE: Annotoations - was (RE: ROHC-FN Snapshot - Wednesd ay's update )

From: "Finking, Robert" <[email-masked]>
Date: Mon, 4 Oct 2004 09:57:15 +0100

I guess it depends if you're hand coding the parser or not, and also whether
you want to stick to single character lookahead or not (which makes things a
lot simpler of course).

Probably I better let Carsten answer this anyway!

Cheers

Raffles

-----Original Message-----
From: Kristofer Sandlund [mailto:[email-masked]] 
Sent: Monday, October 04, 2004 9:51 AM
To: Finking, Robert
Cc: 'Lars-Erik Jonsson (LU/EAB)'; Ghyslain Pelletier (LU/EAB); 'Carsten
Bormann'; [email-masked]'
Subject: Re: [rohc] RE: Annotoations - was (RE: ROHC-FN Snapshot - Wednesd
ay's update )

To me, this is a non-valid argument. I've writen a few parsers in my life,
and I 
cannot see why any parser cannot have one treatment (use this) for a comment

starting with %[ and another one (throw this away) for a comment that starts

with % followed by anything other than [ .

Not that it matters to me what signs we use for comments/annotations, but I 
cannot for the life of me understand why this would be "[a] complete
nightmare". 
We've said that we would not allow extensions to the annotation syntax, so
you 
will never have to check against "arbitrary freeform English text". Right?

/Kristofer Sandlund, Effnet AB

Finking, Robert wrote:
> OK, well I guess this is a moot point now, but seeing as you're
interested...
> 
> The way tool writing tools work, you can easily specify comment
characters. These are then completely ignored. If you want to include
annotations in a comment, what you are doing is effectively getting rid of
any notion of comments from the tools point of view. It can no longer throw
them all away regardless, it now has to treat them all individually and
check if there is any special syntax. This can quickly complete nightmare as
you have to deal with any arbitrary freeform English text that you come
across. What you want is a special comment, which is different from an
ordinary comment, that the tool *won't* treat as a comment, but will treat
as part of the main syntax, so that it can process it (and here's the
important bit) just like any other syntactical element of the language.
> 
> I hope this helps!
> 
> Regards
> 
> Raffles
> 
> PS It's probably worth adding that I haven't seen or used Carsten/Eilert's
tool, don't even know what language it's written in or what platform it runs
on. The above are just general issues to do with parsing.
> 
> -----Original Message-----
> From: Lars-Erik Jonsson (LU/EAB) [mailto:[email-masked]] 
> Sent: Monday, October 04, 2004 9:28 AM
> To: Ghyslain Pelletier (LU/EAB); 'Carsten Bormann'; Kristofer Sandlund
> Cc: Finking, Robert; [email-masked]'
> Subject: RE: [rohc] RE: Annotoations - was (RE: ROHC-FN Snapshot - Wednesd
ay's update )
> 
> 
> 
>>>>       uncompressed_format  =   discriminator,    %[  8 ]
>>>
>>>fine (but won't be checked by tool)
>>
>>Why can't it be checked by a tool?
>>Doesn't the [ 8 ] only apply to the right-hand side of the statement?
> 
> 
> I have the same question. Maybe it can't be checked by your tool
> because of the way you have written it, but I fail to understand
> why it should not be possible to write a tool that would check it.
> 
> /L-E 
> 

_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 4 Oct 2004 11:21:33 +0200

> Probably I better let Carsten answer this anyway!

Our tool is written in Prolog.
Prolog DCGs can do unlimited look-ahead (without these we would never 
have been able to parse the near-unparseable Lulea syntax...).

It is unsavory, but not particularly hard to implement, to change the 
syntax to look for special comments after delimiter symbols and relate 
the contents of these comments to what was before the delimiter symbol. 
  I'll certainly bow to any rough consensus that emerges.

Gruesse, Carsten