The scalac parser has to invoke a specific XML parser to parse an XML literal. That’s a fixed dependency. If you want to have a different parser you have to hack the compiler.
Predef contains a special $scope entry for namespace management, that the compiler knows about.
The parser generates XML trees invoking specific methods from scala.xml.
There might be other dependencies as well. Could this be factored out in a general XML implementation API, to be provided by general XML libraries? Maybe, but I believe it would be quite messy. But that’s not all. Scala is a language, not a compiler. So if we want to open up XML to alternative implementations we have to put the internal compiler XML API in the language spec. This, to me, is intolerably ugly.
Compare how simple it is to treat XML as interpolated strings. You get the xml interpolator from some library and that’s it! Nothing to burden the language with.
The same argument can be applied to the feature of for comprehension. We had put the internal compiler API (map / flatMap / withFilter) in the language specification. This, to me, is intolerably ugly.
Shall we submit a proposal to remove for comprehension from the language?
The main idea is that if it is done everybody will win.
The compiler writers can spend more time on more important things.
I am not expert on compiler writing, but I have small experience with antlr. Use xml with dsl grammar was a real headache. If I had written xml parser and dsl parser separately I spent 2 times less time. And even if the good lexer already have been written it need resources on support.
The xml users will be use more advanced xml library.
Now I use internal xml library by default. And when I read this topic I understand that it is a trap.
The internal xml library will never be improved.
And so on.
So I think remove XML will be more honest.(if there are simple way to migrate old code)
Exactly, removing xml literals isn’t actually necessary for library development, so let’s be honest about that.
Yangbo is attempting to point out how it isn’t that simple. I can understand why odersky may not care for the rhetorical argument, but asking for user feedback and then leaving when you don’t like what you hear isn’t a good look, nor is it likely to result in a technically sound decision.
On idea the migration should not be hard. We need string interpolator and scalafix rule.
But I also don’t understand, Who wiil do it, and when will it be done?
No a for expression can be usefully used in just about any but the smallest of programmes, whereas there are huge Scala programmes that have no need for XML literals.
In the JavaScript world JSX is just a transpiler. Can’t this be done also for Scala - a compiler plugin? Maybe first implementation could be official and then it could be passed to the community.
I’ll jump into this fray briefly to present the side from education. Currently I teach XML in both CS1 and CS2 and I only made the decision to do that in CS1 because it had language level support. Having said that, I am fully on board with the idea of removing them in Scala 3 as I feel that a string interpolation library can give me something that is roughly equally easy to work with and if helps to simplify the compiler as well as the language spec. On the whole, I think that this is the right direction for the language to move in, even if it means a bit of work for me to update my teaching materials. I think it is important for students to learn about some text encoding format (XML, JSON, etc) early on, but I see no reason why any one of those should have language level support instead of striving for all of them to have good library level support.
I want to make this clear: listening to feedback is key. We all, no matter what our background is, will listen to feedback we disagree with. We can make an effort to try to understand others, and I know all committee members will do that. However, listening to feedback does not mean we will agree with it and act on it, nobody has done a promise to act on every suggestion that is brought up in the forums. So I find this comment out of line; disagreements will happen. Let’s be proactive and specific when defending positions, rather than hand waivy and general. We’re all here to find points in common and improve the language for the better.
I agree completely with @jvican
It is important that we all understand that we are all here because we care for the future of Scala. We might not agree what that future is, but I trust the committee to listen to all opinions when it determines that future.
I’m all in favor of making this change. XML literals should never have been part of the language.
I don’t know enough about dotty compiler internals to know, but I’m curious if a compiler plugin could be used to satisfy the needs of those for whom xml string interpolation won’t cut it.
XML literals are the building block for the Storytelling feature of Kojo (www.kojo.in), a learning environment for children. Within Kojo, Stories can be written by both teachers and children to explain ideas to others.
Here are a couple of Story examples that show how XML literals are used within Kojo:
(1) Interactively learn how to solve equations (with an infinite number of practice questions available via a ‘Next Question’ button):
(2) Support for Point and click coding for very young children:
In an ideal world, it would be great to have XML literals around in Scala 3.