I didn't want to merely pile on, but if voting is encouraged I think it's a plus. C's optional trailing comma is a pleasant touch.
greg On Tue, 6 Sep 2016, Brad Chamberlain wrote: > > Speaking from the historical perspective, I don't think there's any > inherent reason to not support trailing commas. We didn't originally > support them because it seemed "sloppy", but then later added them for the > 1-tuple case out of necessity. Though I think we batted it around, we > didn't add them to other cases at that time to minimize the delta more > than anything. > > Personally, I don't feel strongly one way or the other on this one and > will go with the majority. If anybody had qualms, I'd be curious to hear > them (as well as additional +1's for the proposal). > > -Brad > > > On Tue, 6 Sep 2016, Michael Ferguson wrote: > >> Hi - >> >> I'm also for Russel's proposal to allow extra trailing commas. >> >> Does anybody object to the proposal? >> >> Cheers, >> >> -michael >> >> On 9/6/16, 2:17 PM, "David G. Wonnacott" <[email protected]> wrote: >> >>> >>> >>> >>> The trailing-comma feature is one of the (relatively few) things I really >>> like about Python, and I'd be happy to see it added to Chapel. In >>> particular, when debugging, I sometimes like to be able to have a list of >>> complex objects, with a comma at the end of >>> each line, and a final ")" on a line by itself. I can then "comment out" >>> various elements without having to worry about having commented out the >>> last element and thus needing to remove a trailing "," on the most recent >>> non-comment line. >>> >>> So, if anyone is counting responses for or against, count me as "for" >>> this. >>> >>> Dave W >>> >>> On 09/06/2016 01:55 PM, Russel Winder wrote: >>> >>> >>> I raised this point elsewhere and it was suggested I bring it here with >>> a view to there being a change in the Chapel parser. >>> >>> Some language treat a trailing comma in a list or tuple literal as not >>> a problem. Many language, including currently Chapel, treat this as an >>> error. For many this is a trivial non-issue. For some, people who >>> construct tables of data for things like tests or application >>> configuration, it becomes a real irritant. >>> >>> As with other language that have tuple literals Chapel requires a >>> trailing comma in a tuple literal of one element: >>> >>> (1,) >>> >>> completely understandable, indeed required. However Chapel as many >>> other language does not allow a trailing literal in any other >>> situation: so >>> >>> (1, 2,) >>> >>> would be an error. This is a trivial point in many ways, but leads to >>> huge irritations. If only this were allowed many hors of pain and >>> anguish would be averted. Witness Python and other languages that allow >>> the redundant trailing comma: >>> >>> [] >>> [1], [1,] >>> [1, 2], [1, 2,] >>> >>> () >>> (1,) >>> (1, 2), (1, 2,) >>> >>> are all legal in language allowing trailing redundant comma. In >>> languages that do not allow this, literal data manipulation become a >>> right royal pain in the proverbials. >>> >>> Personally I see no reason at all for not allowing this element of >>> redundancy. I believe the Chapel grammar should be amended to allow >>> this. >>> >>> >>> >>> -------------------------------------------------------------------------- >>> ---- >>> >>> >>> _______________________________________________ >>> Chapel-users mailing list >>> [email protected]https://lists.sourceforge.net/lists/list >>> info/chapel-users >>> >>> >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> Chapel-users mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/chapel-users >> > > ------------------------------------------------------------------------------ > _______________________________________________ > Chapel-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/chapel-users > ------------------------------------------------------------------------------ _______________________________________________ Chapel-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/chapel-users
