Update 2018-08-30-sip-minutes.md

Author: darjutak

_sips/minutes/2018-08-30-sip-minutes.md

@@ -51,16 +51,20 @@ Minutes were taken by Darja Jovanovic.
 ### Opening Remarks
 
 **Jorge** opens the meeting, explains SIP dynamics:
+
 Selected batches (proposals for language change in Scala 3) are published on Contributors
+
 Community has 1 month deadline to discuss the proposals
+
 Committee summarises the comments and discusses during the meeting
+
 Decision / voting / postponing the discussion
 
-[More in May 2018 minutes](https://docs.scala-lang.org/sips/minutes/2018-05-18-sip-minutes.html)]
+[More in May 2018 minutes](https://docs.scala-lang.org/sips/minutes/2018-05-18-sip-minutes.html)
 
 ### Summaries of discussions of the First Scala 3 batch
 
-###[“Proposal to remove auto application from the language”](https://contributors.scala-lang.org/t/proposal-to-remove-auto-application-from-the-language/2145)
+### [“Proposal to remove auto application from the language”](https://contributors.scala-lang.org/t/proposal-to-remove-auto-application-from-the-language/2145)
 ([YouTube time: 2’15’’ - 11’22’’ ](https://youtu.be/gnlL4PlstFY?t=136))
 
 **Miles Sabin**  summarised discussion on Contributors thread.
@@ -142,47 +146,63 @@ Summary:
 
 **Conclusion** **Jorge** takes the task to merge the proposals and extend the motivation.  
 
-**Sébastien** [YouTube time” 14’53’ - 40’10’’](https://youtu.be/gnlL4PlstFY?t=891) summarised discussion on Contributors thread [“Proposal to remove XML literals from the language”](https://contributors.scala-lang.org/t/proposal-to-remove-xml-literals-from-the-language/2146) 
+
+### [“Proposal to remove XML literals from the language”](https://contributors.scala-lang.org/t/proposal-to-remove-xml-literals-from-the-language/2146)
+
+**Sébastien** [YouTube time” 14’53’ - 40’10’’](https://youtu.be/gnlL4PlstFY?t=891) summarised discussion on Contributors thread. 
+
 Summary: 
-In favor of the removal
-Significant language specification weight, as well as compiler implementation. The whole XML spec must be embedded in Scala!
-scala-xml is very complicated, and has serious usability problems
-Adding the extra xml"""...""" shouldn’t be a bother
-For JSX-style support, maybe a jsx"" interpolator could have the same semantics as JSX, rather than that of scala-xml
-Direct language support for XML only existed because string interpolators did not exist back then (supposedly). It seems to be an obviously better design to build on string interpolators.
-Removes XML as a special case. With interpolators, one can embed arbitrary languages within Scala.
-Similar argument: XML should have no higher place in the language than YAML, JSON, etc.
-JSX-style use cases should use ScalaTags-style libraries anyway.
-XML being part of the language is the reason that XML libraries have stalled, and that JSON ones have flourished
-Counter-argument: lib stalling is due to the “symbol”-based translation. A name-based translation would not have this issue.
+
+In favor of the removal:
+
+- Significant language specification weight, as well as compiler implementation. The whole XML spec must be embedded in Scala!
+
+- scala-xml is very complicated, and has serious usability problems
+
+- Adding the extra xml"""...""" shouldn’t be a bother
+ - For JSX-style support, maybe a jsx"" interpolator could have the same semantics as JSX, rather than that of scala-xml
+- Direct language support for XML only existed because string interpolators did not exist back then (supposedly). It seems to be an obviously better design to build on string interpolators.
+- Removes XML as a special case. With interpolators, one can embed arbitrary languages within Scala.
+ - Similar argument: XML should have no higher place in the language than YAML, JSON, etc.
+- JSX-style use cases should use ScalaTags-style libraries anyway.
+- XML being part of the language is the reason that XML libraries have stalled, and that JSON ones have flourished
+ - Counter-argument: lib stalling is due to the “symbol”-based translation. A name-based translation would not have this issue.
+
 Against the removal
-Difficulty of syntax highlighting
-Shouldn’t be a real issue as long as editors are on board
-The promised XML interpolator was never materialized
-JSX is now in widespread use in languages for front-end development. It is ironic that Scala would drop support for a similar feature now. It is even built in some languages, e.g., TypeScript.
-JSX is simpler than scala-xml, though: no namespace support, in particular.
-For front-end devs looking at Scala/Scala.js, string interpolators will look horrible compared to JSX, and it might be one of those “no-no” things that will push them away.
-Being able to just copy-paste examples from the Net is nice. (8 Likes on this one)
-No one uses XML anymore, right?
-Some answer that they do. Especially in non-greenfield projects.
-Kojo uses XML literals as building blocks for the Storytelling feature.
+
+- Difficulty of syntax highlighting
+ - Shouldn’t be a real issue as long as editors are on board
+- The promised XML interpolator was never materialized
+- JSX is now in widespread use in languages for front-end development. It is ironic that Scala would drop support for a similar feature now. It is even built in some languages, e.g., TypeScript.
+ - JSX is simpler than scala-xml, though: no namespace support, in particular.
+- For front-end devs looking at Scala/Scala.js, string interpolators will look horrible compared to JSX, and it might be one of those “no-no” things that will push them away.
+- Being able to just copy-paste examples from the Net is nice. (8 Likes on this one)
+- No one uses XML anymore, right?
+ - Some answer that they do. Especially in non-greenfield projects.
+ - Kojo uses XML literals as building blocks for the Storytelling feature.
+
 Counter-proposal
+
 Named-based XML desugaring: https://contributors.scala-lang.org/t/pre-sip-name-based-xml-literals/2175
-Less complexity in the language/compiler
-Open for library competition
-Compared to a string interpolator, flavors can be implemented using normal library code, without (whitebox) macros.
-Whiteboxness is necessary for xml”””<button …></button>””” to return a more precise type such as `xml.tags.Button` rather than `xml.Node`
+
+- Less complexity in the language/compiler
+- Open for library competition
+- Compared to a string interpolator, flavors can be implemented using normal library code, without (whitebox) macros.
+ - Whiteboxness is necessary for xml”””<button …></button>””” to return a more precise type such as `xml.tags.Button` rather than `xml.Node`
+
 Other ideas
-Can it be a compiler plugin or a macro?
-No, a compiler plugin cannot hook into the parser, neither can a macro.
+- Can it be a compiler plugin or a macro?
+  - No, a compiler plugin cannot hook into the parser, neither can a macro.
+
 Related links
-Other XML libraries:
-https://note.github.io/xml-lens/
-One in scalaz-deriving: https://gitlab.com/fommil/scalaz-deriving/tree/master/examples/xmlformat/src/main/scala/xmlformat (link behind a login wall, it seems)
-JSX-style libraries for Scala:
-https://github.com/OlivierBlanvillain/monadic-html
-Binding.scala, TODO app: https://scalafiddle.io/sf/dGkVqlV/9
-Ammonite script to convert HTML to the VDOM DSL of scalajs-react (a ScalaTags flavor):
+
+- Other XML libraries:
+ - https://note.github.io/xml-lens/
+ - One in scalaz-deriving: https://gitlab.com/fommil/scalaz-deriving/tree/master/examples/xmlformat/src/main/scala/xmlformat (link behind a login wall, it seems)
+- JSX-style libraries for Scala:
+ - https://github.com/OlivierBlanvillain/monadic-html
+ - Binding.scala, TODO app: https://scalafiddle.io/sf/dGkVqlV/9
+- Ammonite script to convert HTML to the VDOM DSL of scalajs-react (a ScalaTags flavor):
 https://gist.github.com/nafg/112bf83e5676ed316f17cea505ea5d93
 
 Discussion: