headers
Sam Robertson | 14 Oct 1999 21:19
Picon

Inline comments?

I'm trying to provide end-user UI and store some necessary 'flags' or
'code' within a line in the sieve code, but in order to make my UI as
flexible as possible I need to have inline comments like the /* */ in
C/C++ in Sieve.  I could easily just use # comments and split a simple
line of code up over multiple lines, but that affects readability which
makes administration difficult without my UI.

Has there been any consideration of adding inline comments, and if not
is there anything that would prevent us from supporting this in Sieve?

Example:  if size :over /* this is an inline comment */ 100K { # this is
a comment
                discard;
             }

Obviously the text within and including the /* */ would be ignored as
white space.  I can live with the text: "body" not allowing comments,
and thus not requiring any kind of special processing beyond
dot-stuffing and EOM.

Any thoughts here?

Sam
Permalink | Reply | 9 comments |
headers
Tony Hansen | 14 Oct 1999 21:59
Picon
Favicon

Re: Inline comments?

Sam Robertson wrote:
> 
> I'm trying to provide end-user UI and store some necessary 'flags' or
> 'code' within a line in the sieve code, but in order to make my UI as
> flexible as possible I need to have inline comments like the /* */ in
> C/C++ in Sieve.  I could easily just use # comments and split a simple
> line of code up over multiple lines, but that affects readability which
> makes administration difficult without my UI.
> 
> Has there been any consideration of adding inline comments, and if not
> is there anything that would prevent us from supporting this in Sieve?
> 
> Example:  if size :over /* this is an inline comment */ 100K { # this is
> a comment
>                 discard;
>              }
> 
> Obviously the text within and including the /* */ would be ignored as
> white space.  I can live with the text: "body" not allowing comments,
> and thus not requiring any kind of special processing beyond
> dot-stuffing and EOM.

Sounds worthy of supporting.

	Tony Hansen
	tony <at> att.com
Permalink | Reply | 3 comments |
headers
Sam Robertson | 19 Oct 1999 21:23
Picon

Re: Inline comments?

Anyone else have any thoughts on this?  Is this something we might be
able to add to the next version of the draft?

Sam

Tony Hansen wrote:
> 
> Sam Robertson wrote:
> >
> > I'm trying to provide end-user UI and store some necessary 'flags' or
> > 'code' within a line in the sieve code, but in order to make my UI as
> > flexible as possible I need to have inline comments like the /* */ in
> > C/C++ in Sieve.  I could easily just use # comments and split a simple
> > line of code up over multiple lines, but that affects readability which
> > makes administration difficult without my UI.
> >
> > Has there been any consideration of adding inline comments, and if not
> > is there anything that would prevent us from supporting this in Sieve?
> >
> > Example:  if size :over /* this is an inline comment */ 100K { # this is
> > a comment
> >                 discard;
> >              }
> >
> > Obviously the text within and including the /* */ would be ignored as
> > white space.  I can live with the text: "body" not allowing comments,
> > and thus not requiring any kind of special processing beyond
> > dot-stuffing and EOM.
> 
> Sounds worthy of supporting.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Tim Showalter | 21 Oct 1999 04:26

Re: Inline comments?

samr <at> Netscape.COM (Sam Robertson) writes:

> Anyone else have any thoughts on this?  Is this something we might be
> able to add to the next version of the draft?

I'm sorry I put off responding to this.

I'm not fond of it, but other than feature creep, I have no objection
to it.  I would like to know, though, what you're hiding in comments.
If it's important enough to have in the script, it would seem to be
important enough to represent in the syntax.

Thanks...

Tim
Permalink | Reply | 1 comment |
headers
Sam Robertson | 21 Oct 1999 04:47
Picon

Re: Inline comments?

Tim,

Thanks for the response.  What I'm trying to do is build a flexible UI
that let's administrators create any 'sieve' script they want while at
the same time being able to present the script to the user in some kind
of real world representation.  The reason for this, is that we don't
think many admins would want users to have the ability to write their
own scripts, but we don't want to restrict administrators to only
providing the scripts we come up with.

So, what I've done is use the comments to hide certain 'key' information
that makes it possible for the parsing engine that presents this
flexible UI to figure out where user selectable fields would go.  I
can't think of another way of offering such a UI without requiring an
admin to write their own code for each of the scripts.  

In a typical example this is what an administrator would create as a
template for the UI:

disclaimer:  This is just an idea that I came up with, and is not
necessarily the easiest or best way to implement it, but this shows what
I think to be a fairly simple way to implement flexible UI.

---- template1.txt ---- 
# $Rule Info: Template="File To Folder" 
if header :is <Q1> <Q2> 
{ 
            fileinto <Q3>; 
}
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tim Showalter | 22 Oct 1999 02:24

Re: Inline comments?

samr <at> Netscape.COM (Sam Robertson) writes:

> Obviously the text within and including the /* */ would be ignored as
> white space.  I can live with the text: "body" not allowing comments,
> and thus not requiring any kind of special processing beyond
> dot-stuffing and EOM.

To simplify the lexer's problem a bit, only a # comment is allowed
after "text:".  I really don't want a /**/ comment there, but I'd be
happy to change it to disallow ALL comments.

Here's the change to the nroff source.  Please look at the grammar and 
tell me if I got the bracketed comment production right.

There's nothing Sieve-related going on at the IETF to the best of my
knowledge.  I'll Last Call this real soon now, especially if this is
the only change.

If anyone has any outstanding changes to the vacation spec, I'd like
to know about those as well.

--- sieve.ms.19991021	Thu Oct 21 15:50:54 1999
+++ sieve.ms	Thu Oct 21 17:20:40 1999
 <at>  <at>  -471,10 +471,12  <at>  <at> 

 .xx "2.3.     Comments"

-Comments begin with a "#" character that is not contained within a string and
-continue until the next CRLF.  Comments are semantically equivalent to
+Two types of comments are offered.  Comments are semantically equivalent to
(Continue reading)

Permalink | Reply | 4 comments |
headers
Lawrence Greenfield | 22 Oct 1999 02:59
Picon

Re: Inline comments?

[...]
   +Bracketed comments begin with the token "/*" and end with "*/".
   +Bracketed comments may span multiple lines.  Bracketed comments do not
   +nest.

I would greatly prefer that these comments do nest since I think it
makes more sense logically and allows use of such comments to comment
out large sections of code (the only use I would have for these
comments over the "#"-style).

Since I still doubt the utility of these comments (a parsing engine
can just as easily parse the actual Sieve script instead of simply
looking for certain comments) I'm not really attached to having them
nest.

Larry
Permalink | Reply | 1 comment |
headers
Tony Hansen | 22 Oct 1999 18:47
Picon
Favicon

Re: Inline comments?

Lawrence Greenfield wrote:
> 
> [...] Bracketed comments do not nest.
> 
> I would greatly prefer that these comments do nest since I think it
> makes more sense logically and allows use of such comments to comment
> out large sections of code (the only use I would have for these
> comments over the "#"-style). ...

I could live either way.

	Tony Hansen
	tony <at> att.com
Permalink | Reply | 0 comments |
headers
Tony Hansen | 22 Oct 1999 18:44
Picon
Favicon

Re: Inline comments?

Tim Showalter wrote:
> 
> samr <at> Netscape.COM (Sam Robertson) writes:
> 
> > Obviously the text within and including the /* */ would be ignored as
> > white space.  I can live with the text: "body" not allowing comments,
> > and thus not requiring any kind of special processing beyond
> > dot-stuffing and EOM.
> 
> To simplify the lexer's problem a bit, only a # comment is allowed
> after "text:".  I really don't want a /**/ comment there, but I'd be
> happy to change it to disallow ALL comments.

I started out to say that /**/ comments should be allowed there, but the
more I thought about it, the more problems I saw. (E.g., what happens if
a /**/ comment wants to span lines after the "text:", how about only
allowing single-line /**/ comments there, ugh, double-ugh, etc. :-) ) At
the same time, I think that allowing one type of comment there but not
the other is a mistake. So I'm agreeing with you that it would be better
to disallow all types of comments after "text:" up to the CRLF.

	Tony Hansen
	tony <at> att.com
Permalink | Reply | 1 comment |
headers
Lawrence Greenfield | 22 Oct 1999 19:06
Picon

Re: Inline comments?

[...]
   > To simplify the lexer's problem a bit, only a # comment is allowed
   > after "text:".  I really don't want a /**/ comment there, but I'd be
   > happy to change it to disallow ALL comments.

   I started out to say that /**/ comments should be allowed there, but the
   more I thought about it, the more problems I saw. (E.g., what happens if
   a /**/ comment wants to span lines after the "text:", how about only
   allowing single-line /**/ comments there, ugh, double-ugh, etc. :-) ) At
   the same time, I think that allowing one type of comment there but not
   the other is a mistake. So I'm agreeing with you that it would be better
   to disallow all types of comments after "text:" up to the CRLF.

The problem with the "text:" construct is that it differentiates one
sort of whitespace (SPC) from another (CRLF).  Since we already do
that, I don't really have a problem with comments there.  Comments
should be equivalent to whitespace.

If I can remove a /* */ and insert a SPC and have a legal program,
then the comment should be legal.

If I can remove a #... and insert a CRLF and have a legal program,
then the comment should be legal.

Larry
Permalink | Reply | 0 comments |

Gmane