<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On May 18, 2016, at 10:51 AM, David Hart <<a href="mailto:david@hartbit.com" class="">david@hartbit.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Could you show me an example of a fictional EDSL that gets better with newline separated lists?</div></div></blockquote><div><br class=""></div><div>I’ll do better than that. I’ll show and example of a real EDSL I implemented in Ruby in the early days of iOS. It was used to generate very efficient streaming SAX-style XML parsers which parsed the data directly into model objects without building an intermediate DOM (validating the data in the process). The generated parsers were implemented in Objective-C with some use of C code in the implementation.</div><div><br class=""></div><div>Here is a sample in Ruby:</div><div><br class=""></div><div>object :attribute1, :class => :ObjectiveCClassName do</div><div> integer :id</div><div> string :description</div><div> bool :is_active, :property => :isActive</div><div> date :created_at, :property => :createdAt</div><div> array :items do</div><div> object :item, :class => :AnotherObjectiveCClass do</div><div> float :amount</div><div> end</div><div> end</div><div>end</div><div><br class=""></div><div>The EDSL was used to build a data structure describing the expected schema and how it maps to the model objects. That schema was used to generate the parser.</div><div><br class=""></div><div>You would probably do some things different in Swift but a relatively direct translation will suffice to demonstrate how removing commas is desirable. This example will assume Swift is also the target language. </div><div><br class=""></div><div>Operators are used so that the structure of the EDSL follows the Ruby closer rather than nesting the array inside of the parameter list). Please ignore the specific operator “names". I just selected something arbitrary.</div><div><br class=""></div><div>Here is what we would have in Swift with commas (I modified the EDSL slightly to make it more type-safe as it was intended to have only one child node for `array` to define the element type):</div><div><br class=""></div><div>object (“attribute1”, type: ASwiftType) ++++ [</div><div> integer (“id”),</div><div> string (“description”),</div><div> bool (“is_active”, property: “isActive”),</div><div> date (“created_at”, property: “createdAt”),</div><div> array (“items”) >>>> object (“item”, type: AnotherSwiftType) ++++ [</div><div> float (“amount”)</div><div> ]</div><div>]</div><div><br class=""></div><div>And here without commas:</div><div><br class=""></div><div><div>object (“attribute1”, type: ASwiftType) ++++ [</div><div> integer (“id”)</div><div> string (“description”)</div><div> bool (“is_active”, property: “isActive”)</div><div> date (“created_at”, property: “createdAt”)</div><div> array (“items”) >>>> object (“item”, type: AnotherSwiftType) ++++ [</div><div> float (“amount”)</div><div> ]</div><div>]</div></div><div><br class=""></div><div>The difference isn’t super significant, but IMO every bit of unnecessary / undesirable syntactic noise in an EDSL is a flaw. The less noise the language requires the better it is for creating EDSLs. You want to be able to approximate the syntax you might design from scratch relatively closely. </div><div><br class=""></div><div>In this case, items in the list are essentially statements / declarations in the EDSL. You don’t want commas here for the same reason we appreciate the omission of semicolons as line terminators in Swift and other modern languages.</div><div><br class=""></div><div>The obvious advantage of using Swift is that you can design the EDSL to have very strict types and reject anything invalid at compile time.</div><div><br class=""></div><div>The Ruby still feels slightly cleaner to me because Ruby allows you to omit parentheses for expressions that only involve a single method call. Ruby also has symbols which are lighter syntactically than string literals. Both of these are also features that might be interesting to consider adding to Swift IMO. For the sake of argument (but without considering whether that would be practical in the Swift grammar, and whether Swift would borrow Ruby’s colon for symbols) here is what you might be able to do in Swift if we do get those features:</div><div><br class=""></div><div>(object :attribute1, type: ASwiftType) ++++ [<br class=""> integer :id<br class=""> string :description<br class=""> bool :is_active, property: :isActive<br class=""> date :created_at, property: :createdAt<br class=""> (array :items) >>>> (object item, type: AnotherSwiftType) ++++ [<br class=""> float :amount<br class=""> ]<br class="">]</div><div><br class=""></div><div>This roughly as good as the Ruby, a language which is praised for the flexibility it allows in designing EDSLs. Pretty cool! (Of course while I loved it in Ruby, I imagine there would be a lot of controversy if we do ever consider allowing simple expressions to omit parentheses in Swift)</div><div><br class=""></div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On 18 May 2016, at 16:02, Matthew Johnson <<a href="mailto:matthew@anandabits.com" class="">matthew@anandabits.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class=""><div class=""><br class=""><br class="">Sent from my iPad</div><div class=""><br class="">On May 18, 2016, at 8:08 AM, David Hart via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div class="">It would cumbersome to transform to newline-separated list to a comma-seperated list, because you’d have to add a character on top of removing the newline.</div></div></blockquote><div class=""><br class=""></div>The way I edit code this would not add any extra keystrokes. Select new line, insert comma rather than select new line and press delete.<div class=""><br class=""></div><div class="">This feature would be fantastic when making EDSLs in Swift. It would help them come out much cleaner any time they include a comma separated list that is likely to be formatted on individual lines. </div><div class=""><br class=""></div><div class="">Big +1 from me.</div><div class=""><br class=""></div><div class=""><br class=""><blockquote type="cite" class=""><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On 18 May 2016, at 14:20, Patrick Smith <<a href="mailto:pgwsmith@gmail.com" class="">pgwsmith@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">I don’t really see what the issue with having to reintroduce commas would be? The losing track of where the items are separated?</div><div class=""><br class=""></div><div class="">Maybe there could be an Xcode key shortcut to toggle commas off and on for newline separated items, like the current toggler for comments.</div><br class=""><div class=""><blockquote type="cite" class=""><div class="">On 18 May 2016, at 6:28 PM, David Hart via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class=""><div class="">-1 I see one big downside. Contrary to statements, which rarely appear on the same line, other list elements are more frequently reformatted, from one line to multiple lines and back. For example, I'll try to find function declarations with too many arguments (formatted on multiple lines) and refactor them to reduce the number of arguments and reformat them on one line. This style refactoring would be made more difficult because it would force me to re-introduce commas if they had been removed. Summary: I'm against this proposal because element lists can be frequently reformatted from one to multiple lines.</div><div class=""><br class="">On 17 May 2016, at 20:06, Tino Heth via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><meta http-equiv="Content-Type" content="text/html charset=us-ascii" class="">[Due to popular demand ;-) in the discussion of <span style="font-family: 'Helvetica Neue';" class="">SE-0084: Allow trailing commas in parameter lists and tuples]</span><div class=""><br class=""></div><div class=""><font face="Helvetica Neue" class="">The option to skip semicolons for statements followed by a newline is only a tiny convinience, yet it is one of the most favored differences to C (and one of the most annoying things to remember when you have to switch from Swift to do some coding in Objective-C).<br class="">While lists of statements don't need a special separator character anymore, other lists still rely on commas to separate items:<br class="">- method parameters<br class="">- array and dictionary literals<br class=""></font></div><div class=""><font face="Helvetica Neue" class="">- tuples</font></div><div class=""><font face="Helvetica Neue" class="">[anything else?]</font></div><div class=""><font face="Helvetica Neue" class=""><br class=""></font></div><div class=""><font face="Helvetica Neue" class="">SE-0084 targets to make it easier to reorder list elements by allowing an additional comma after the last element; afaics, the same can be achieved by making all of those commas optional, as long as there is a newline to separate the next item (without those newlines, SE-0084 makes less sense as well).</font></div><div class=""><font face="Helvetica Neue" class=""><br class=""></font></div><div class=""><font face="Helvetica Neue" class="">This change is not incompatible with SE-0084, but imho it doesn't make much sense to combine those features (at least </font><span style="font-family: 'Helvetica Neue';" class="">in actual source code).</span></div><div class=""><font face="Helvetica Neue" class=""><br class=""></font></div><div class=""><font face="Helvetica Neue" class="">So, first question:</font></div><div class=""><font face="Helvetica Neue" class="">What are the downsides of this change? (question zero is "are there any other places where comma-separeted lists could be turned into newline-separated lists?"...)</font></div><div class=""><font face="Helvetica Neue" class=""><br class=""></font></div><div class=""><font face="Helvetica Neue" class="">Tino</font></div><div class=""><font face="Helvetica Neue" class=""><br class=""></font></div></div></blockquote><blockquote type="cite" class=""><div class=""><span class="">_______________________________________________</span><br class=""><span class="">swift-evolution mailing list</span><br class=""><span class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a></span><br class=""><span class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br class=""></div></blockquote></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div></div></blockquote></div><br class=""></div></blockquote><blockquote type="cite" class=""><div class=""><span class="">_______________________________________________</span><br class=""><span class="">swift-evolution mailing list</span><br class=""><span class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a></span><br class=""><span class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br class=""></div></blockquote></div></div></div></blockquote></div><br class=""></div></div></div></blockquote></div><br class=""></body></html>