There’s a Scala 3 proposal to remove XML from the language, which would mean that the compiler’s parser would no longer parse XML. For example, the following code will no longer compile.
val p = <person><name>Ken</name><age>23</age></person>
The previous code would need to be written as:
val p = xml"""<person><name>Ken</name><age>23</age></person>"""
There are plans to have a rewrite to go from the former code snippet to the latter. This proposal is open for discussion in the community and will be discussed in our next SIP meeting, where we’ll take all your feedback into account for the approval/dismissal of this feature.
I’m for removing this feature. I think that for better migration it is important to urge/help tooling authors special-case the xml string interpolation syntax for code highlighting and such.
In what way does the xml interpolator need more syntax highlighting? I guess you mean of the xml content? So IntelliJ already has an “Inject language” feature which can highlight strings like any supported language. However last I checked it didn’t get along well with scala string interpolators (it breaks the interpolated scala highlighting). Also, it would be nice if it would do it automatically based on the interpreter. Another candidate would be Slick’s sql interpolator or Quill’s infix interpolator. It would definitely be nice to have that fixed. (But it wouldn’t be special-cased for XML per se.)
As for other tooling, I’m not sure what to expect… FWIW Javascript and some other languages also support custom interpolators, so we could hope that eventually there would be broader support…
Yes, I meant the content. I’m not an XML user, but I don’t think adding the extra xml"" will be a bother. If the editor remains indifferent to the string’s content, then I guess that will present a problem. In short, I think deprecation cycles should take into account the tooling support and not just the compiler.
We did take into account this issue in our past meeting and chatted extensively about it. The conclusion was that we would try to get in touch with IntelliJ maintainers so that xml literals could be detected and highlighted in the interpolated xml strings.
Now that JSX is all the rage on the frontend isn’t it a bit ironic that we’re going to remove xml literals support from the language?
@ashawley has been making great strides with scala-xml, we’ve even got xml literals support in Scala.js now.
Yes, having xml support baked into the language brings maintenance overhead, but how much? Is it really that much of a burden? It seems that Kotlin, Groovy, TypeScript, etc. bring baked in literals support, why shouldn’t Scala have the same?
We use XML very often because:
-it is very easy to generate xsd by pojo classes(Validation\autocompletion is very usefull in configuration files, for example.)
-Our customers often require us to use xml for integration
Does this xml interpolator actually exist already? Because I’ve been reading for years about people wanting it in a library to replace the baked-in literals, but I still haven’t seen it.
Not a compiler dev, but it wouldn’t surprise me if it’s a non-trivial hassle. I mean, the syntax of XML is wildly different from that of Scala, so there’s surely a whole separate parser for it, and edge cases between the two parsers.
I use XML literals sometimes, but I have to say, I’m in favor of this change. Wrapping the XML in xml"" isn’t much hassle, and it’s much more consistent with the way the language has come out over the years. It wasn’t done that way originally because we didn’t have string interpolation originally. But now, I think it’s clearly the better design, and helps cement the point that this is how you embed arbitrary other languages inside Scala – it removes XML as a special case, and simply treats it the same way people often deal with strongly-typed JSON, SQL, and whatever…
Thanks for bringing this up! We actually discussed about JSX and its popularity in our past SIP meeting (sorry for the audio, the equipment wasn’t adequate – you should be able to understand the discussion though): https://www.youtube.com/watch?v=ddvRk2T0CnM.
Are you using JSX in Scala (or are any of your friends)? It would be great to hear from you before making up our minds, we want to consider all possible current uses of XML.
I have not needed XML literals at my day job and I wasn’t hurting for it when I was working on my own Scalajs project. I have written a lot of React code with JSX, but if JSX is not available I wouldn’t lose sleep over it either. My guess is that if there’s a proposal to add JSX syntax to Javascript today, there will be a huge pushback from even the frontend devs themselves.
It is desirable to keep the language simple especially when Scala supports writing DSLs well (operator overloading, string interpolation and the upcoming implicit functions).
Yes, using literals on the frontend via Scala.js since support landed in scala-xml (and was using literals on the backend with Play for about 6 years).
Removing literals support from the compiler makes sense (one less feature to maintain/support), but for frontend devs taking a look at Scala/Scala.js the proposed replacement for xml literals, string interpolation, will invariably result in cries of, “no mames guey”.
ScalaTags seems to be the only real alternative at this point, and for those accustomed to JSX it probably won’t win over many potential converts (needless to say the frontend dev population is enormous).
Maybe Dotty’s ability to replicate Kotlin/Groovy builders could provide a clean-ish literals syntax in a to-be-created library, but that won’t happen before this SIP is accepted or rejected.
Side note: replacing literals with string interpolation will not, as I understand it, rework/fix the myriad issues in scala-xml itself. I’d be fine with ditching the library entirely if a suitable literals alternative is provided (monadic-html looks quite promising but it itself depends on a fork of scala-xml).
Are you kidding? It’s a genuine question, I’m not able to know here.
If you are kidding, it would help to give your real ideas on the subject.
If you are not, let just say that that not everyone is working on greenfield projects, and you are missing the gazillion of existing projects, the one interacting with Java standards, actual framework using it (like lift web), etc etc.
You can’t be so light with the existing ecosystem.
JSX is relatively new and AFAIK very popular. Even Vue.js supports it, and it’s built into Typescript.
That said, it’s a lot simpler than scala xml literals. For instance, AFAIK it doesn’t support XML namespaces, IIUC a major source of issues and complexity in scala-xml.
Mutability, silent side effects (for ex schema resolution), complexity of the general data type(s), performances, no clear separation of concerns (parsing/validation/structure/query/update/…).
Perhaps I’m missing some, but the general feeling is that scala-XML is not nice to use.
For reference, I’m now aware of some recent prototypes for a scala XML lib:
