[Grace-core] Comment proposal

Lex Spoon lex at lexspoon.org
Wed Feb 4 13:25:16 PST 2015


My impression of the proposed rules are that they are broadly in the spirit
of the "preceding syntactic unit" rule that is in the draft specification
now. Some ambiguities have come up with the existing spec, and a natural
way to sharpen the specification is to enumerate individual cases that are
simple to handle. The remaining cases end up being implicitly rejected.

I agree with others that it seems reasonable to allow a comment at the end
of an entire statement, on the same line. That might be a good relaxation
of the given rules.

One issue not mentioned is that two-column styles are a maintenance burden.
So maybe it's not bad to reject such code. To see why, look at this code
given earlier:

     thinList := myList.filter(no_punc)   // get rid of punctuation
                                .toLower             // & change to lower

First, an auto-formatter is very likely to mangle this code. That doesn't
matter for 10-line programs, but it really slows down development on larger
programs if you have to manually format.

Second, if you aren't auto-formatting, look what happens if you rename
"toLower" to "toLowerCase", possibly via a refactoring tool:

     thinList := myList.filter(no_punc)   // get rid of punctuation
                                .toLowerCase             // & change to
lower

Now the comment column doesn't align, and the programmer has to spend time
inserting and removing spaces to fix the layout. It's not the biggest time
sink in the world, but it is a time sink.

For the "canonical example" given earlier, I see a way to rewrite it to
comply with the proposed rules. Just use identifiers instead of comments:

    def space = "\u0020"
    def no_break_space = "\u00A0"
    def ogham_space_mark = "\u1680"

    def spaces = sequence.with(
        , space
        , no_break_space
        , ogham_space_mark)


Not that I care deeply about the issue. I do think there's a lot of group
think about treating comments as white space, though, and that a more
structured approach can be better.

Lex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailhost.cecs.pdx.edu/pipermail/grace-core/attachments/20150204/0d48b325/attachment.html>


More information about the Grace-core mailing list