need XML input

On Tue, May 5, 2009 at 9:09 AM, Paul Phillips <paulp@improving.org> wrote:

I need input from anyone who uses the XML lib as to these two unpleasant
situations.  For each one I would like to know:

 Is this expected?
 Is it specced somewhere?
 Is it acceptable to you? Or god forbid, appealing?

Armed with good answers here I should soon have every XML ticket closed.


*** SITUATION 1 ***

scala> <p>1</p> match { case <p>{ "1" }</p> => true ; case _ => false }
res9: Boolean = true

scala> <p>1</p> match { case <p> { "1" } </p> => true ; case _ => false }
res10: Boolean = false

In fact,

scala> <p> { "1" } </p> match { case <p> { "1" } </p> => true ; case _ => false }
res6: Boolean = false

Is that second version ever going to match? If so, with what?

I do not use pattern matching with XML literals.  The whole extraction, etc. stuff is very, very difficult to get right.  I'd be in favor of removing XML pattern matching from the language.  Matching against Elem, etc. does just fine.
 

*** SITUATION 2 ***

scala> <x y={ Some(Text("foo")) } />
res13: scala.xml.Elem = <x y="foo"/>

scala> <x> { Some(Text("foo")) } </x>
res14: scala.xml.Elem = <x> Some(foo) </x>

This I feel is madness.  Do people rely on it, intentionally I mean?

I agree with the madness.

I would be in favor of doing something with implicits (if it's at all possible) to do conversion from T to NodeSeq... and perhaps there's an conversion someplace that is from Option[NodeSeq] -> NodeSeq.

 

--
Paul Phillips      | One way is to make it so simple that there are
Everyman           | obviously no deficiencies. And the other way is to make
Empiricist         | it so complicated that there are no obvious deficiencies.
pull his pi pal!   |     -- Hoare

--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp

On Tue, May 5, 2009 at 10:16 AM, David Pollak wrote: > > > On Tue, May 5, 2009 at 9:09 AM, Paul Phillips wrote: >> >> I need input from anyone who uses the XML lib as to these two unpleasant >> situations.  For each one I would like to know: >> >>  Is this expected? >>  Is it specced somewhere? >>  Is it acceptable to you? Or god forbid, appealing? >> >> Armed with good answers here I should soon have every XML ticket closed. >> >> >> *** SITUATION 1 *** >> >> scala>

1

match { case

{ "1" }

=> true ; case _ => false } >> res9: Boolean = true >> >> scala>

1

match { case

{ "1" }

=> true ; case _ => false } >> res10: Boolean = false >> >> In fact, >> >> scala>

{ "1" }

match { case

{ "1" }

=> true ; case _ => >> false } >> res6: Boolean = false >> >> Is that second version ever going to match? If so, with what? > > I do not use pattern matching with XML literals.  The whole extraction, etc. > stuff is very, very difficult to get right.  I'd be in favor of removing XML > pattern matching from the language.  Matching against Elem, etc. does just > fine. > Seconded. >> >> *** SITUATION 2 *** >> >> scala> >> res13: scala.xml.Elem = >> >> scala> { Some(Text("foo")) } >> res14: scala.xml.Elem = Some(foo) >> >> This I feel is madness.  Do people rely on it, intentionally I mean? > > I agree with the madness. > > I would be in favor of doing something with implicits (if it's at all > possible) to do conversion from T to NodeSeq... and perhaps there's an > conversion someplace that is from Option[NodeSeq] -> NodeSeq. > This is indeed madness. I'm somewhat skeptical of using implicits in a location like this, with the possible exception of a single implicit conversion from String -> Text. What would be the correct behavior for a conversion from Option? This seems to me to be something that has to be explicitly specified in each case; sometimes I want to leave the element out entirely, sometimes to replace it with a self-closed tag, etc. From my perspective, the brace constructs seem to live somewhere in between string templating and XML element assembly, and it would be much better if the two concerns were separated from one another; of course I've seen the repeated rejection of the notion that string templating is valuable from Martin, so I don't have much hope there. The whole design of MetaData seems bizarre to me from the start; attributes should be orthogonal to nodes and I have a hard time coming up with a sensible reason that a single attribute and a list of attributes are represented by the same object, since attributes can't nest. Kris

On Tue, May 05, 2009 at 09:16:17AM -0700, David Pollak wrote:
> I do not use pattern matching with XML literals. The whole
> extraction, etc. stuff is very, very difficult to get right.

OK, but is that because it's buggy and/or inadequately thought out
and/or unreliable, or somehow inherent? Would you pattern match with XML
literals if it worked predictably?

> I would be in favor of doing something with implicits (if it's at all
> possible) to do conversion from T to NodeSeq... and perhaps there's an
> conversion someplace that is from Option[NodeSeq] -> NodeSeq.

Implicit conversions between Option[T] and T are fundamentally unsound.
Too much blood has already been shed in the name of inconvenient
conveniences. We must put down our implicits and begin the healing.

On Tue, May 05, 2009 at 04:08:30PM -0600, Kris Nuttycombe wrote:
> The whole design of MetaData seems bizarre to me from the start;
> attributes should be orthogonal to nodes and I have a hard time coming
> up with a sensible reason that a single attribute and a list of
> attributes are represented by the same object, since attributes can't
> nest.

When you see an inheritance hierarchy like Seq[Node]->NodeSeq->Node,
it's safe to say that orthgonality has been thrown out the window and
stomped into a bloody pulp. But my interest in XML does not go deep
enough to pursue ambitious restructuring, only to try to close all the
open tickets and fix the most egregious inconsistencies.

Here is the ticket I can't fix without a strategy for point 2 here:

https://lampsvn.epfl.ch/trac/scala/ticket/1787

I modified the compiler generated code to insert a call to toString, and
that's how I discovered the varying Option handling.

On Tue, May 5, 2009 at 4:03 PM, Paul Phillips <paulp@improving.org> wrote:

On Tue, May 05, 2009 at 09:16:17AM -0700, David Pollak wrote:
> I do not use pattern matching with XML literals.  The whole
> extraction, etc. stuff is very, very difficult to get right.

OK, but is that because it's buggy and/or inadequately thought out
and/or unreliable, or somehow inherent? Would you pattern match with XML
literals if it worked predictably?

I don't think so... I'm happy without XML literals in pattern matching.
 

> I would be in favor of doing something with implicits (if it's at all
> possible) to do conversion from T to NodeSeq... and perhaps there's an
> conversion someplace that is from Option[NodeSeq] -> NodeSeq.

Implicit conversions between Option[T] and T are fundamentally unsound.
Too much blood has already been shed in the name of inconvenient
conveniences.  We must put down our implicits and begin the healing.

Yes.
 

On Tue, May 05, 2009 at 04:08:30PM -0600, Kris Nuttycombe wrote:
> The whole design of MetaData seems bizarre to me from the start;
> attributes should be orthogonal to nodes and I have a hard time coming
> up with a sensible reason that a single attribute and a list of
> attributes are represented by the same object, since attributes can't
> nest.

When you see an inheritance hierarchy like Seq[Node]->NodeSeq->Node,
it's safe to say that orthgonality has been thrown out the window and
stomped into a bloody pulp.  But my interest in XML does not go deep
enough to pursue ambitious restructuring, only to try to close all the
open tickets and fix the most egregious inconsistencies.

Here is the ticket I can't fix without a strategy for point 2 here:

 https://lampsvn.epfl.ch/trac/scala/ticket/1787

I modified the compiler generated code to insert a call to toString, and
that's how I discovered the varying Option handling.

--
Paul Phillips      | Where there's smoke, there's mirrors!
Protagonist        |
Empiricist         |
all hip pupils!    |----------* http://www.improving.org/paulp/ *----------

--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp

Paul Phillips wrote:
> On Tue, May 05, 2009 at 09:16:17AM -0700, David Pollak wrote:
>
>> I do not use pattern matching with XML literals. The whole
>> extraction, etc. stuff is very, very difficult to get right.
>>
> OK, but is that because it's buggy and/or inadequately thought out
> and/or unreliable, or somehow inherent? Would you pattern match with XML
> literals if it worked predictably?
>
It would be really nice to be able to decompose XML documents with
patterns in idiomatic form, but the syntax and/or implementation may
well turn out to be unconscionable.

e.g.

val doc =

doc match {
case // specific
pattern, no match
case {kids @ _*} // Matches (see whitespace
comment below); sets url, kids
case {_} // Matches; @href and at
least one child are present but we don't care about the values
case {_} // Matches even if there are
additional attributes
}

Of course, namespaces will uglify things to some extent; we kicked
around a few ideas on the subject last year:
http://www.nabble.com/Namespace-support-in-XML-patterns-td17562546.html

As for whitespace, I suspect most people would prefer if XML pattern
matching defaulted to ignoring the whitespace around child elements,
i.e. "case " should match "\n\n \n\n".

Mixed content, namely the juxtaposition of non-whitespace text nodes and
element nodes as siblings under some parent element, is fairly uncommon
in corporate data, although it's the rule in XHTML documents.

One way to address both these concerns might be to have something like
an implicit XMLContext that could hold namespace declarations and supply
user-defined parameters for any heuristic rules that might apply (e.g.
regarding whitespace). A default XMLContext could be chosen that would
DWIM for the majority of users; anyone else could feel free to declare
'implicit val xc = scala.xml.SensitiveWhitespaceAroundElements' or somesuch.

I wish I had more time to work on scala.xml. :/

-0xe1a

On Wed, May 6, 2009 at 3:16 AM, Alex Cruise wrote:
> As for whitespace, I suspect most people would prefer if XML pattern
> matching defaulted to ignoring the whitespace around child elements, i.e.
> "case " should match "\n\n  \n\n".

I'd recommend doing things in exactly the same way as XSLT,

http://www.w3.org/TR/xslt#strip

Hmm ... Copy Java? Copy XSLT? What's that Russell quote about "the
benefits of theft over honest toil"? ;-)

Cheers,

Miles

On Wed, May 06, 2009 at 12:11:27PM +0100, Miles Sabin wrote:
> I'd recommend doing things in exactly the same way as XSLT,
>
> http://www.w3.org/TR/xslt#strip
>
> Hmm ... Copy Java? Copy XSLT? What's that Russell quote about "the
> benefits of theft over honest toil"? ;-)

In case I have unwittingly given any other impression, let me state for
the record that as a general principle I would far, far rather adopt an
existing way of doing something than invent my own. It is only when
all else is not equal that I might look to do otherwise.

I haven't used xml enough (read: almost never) to be able to see any
obvious issues with that suggestion, so it looks great to me. I will
investigate XSLT's algorithm.

David Pollak writes:
> I do not use pattern matching with XML literals.  The whole extraction, etc.
> stuff is very, very difficult to get right.  I'd be in favor of removing XML
> pattern matching from the language.  Matching against Elem, etc. does just
> fine.

You can't be serious!

The XML literals and pattern matching have got to be one of the hottest
features of the language, yet you want them removed because you don't use them?
Those were the very things that made me pause and take a second look at Scala.

You may think this is shallow, but when explaining the benefits of Scala to a
busy and tired Java developer, you don't have much time to talk about the rich
type system, type inference, infix method syntax, first-class functions and how
it all clicks together, before the window of interest is lost.

Why should they care about Scala specifically, when there are lots of other
powerful languages competing for their attention, like Ruby, Python, Groovy,
Erlang, Clojure, Self, Nice, OCaml, Haskel, Io, F# and who knows what else.

On the other hand, when showing the XML literal syntax to DOM-weary Java
developers, they raise their eyebrow, and when you show them the complementary
XML pattern matching, their eyes positively light up. Then you explain that
it's syntactic sugar for matching a bunch of nested classes, that it can match
your own classes too, and they slowly start to realize the power behind the
Scala language, and that maybe they should invest some effort to learn about it
instead of some other language.

XML literals and patterns are like a left-right punch that makes people wake up
and pay attention. Without them it would be difficult to get your foot in the
door, so to speak.

Sure, XML patterns have some problems, I am not disputing that. I will also
grant that I may not use them everytime and everywhere, but in those place that
I did use them, I found that the pattern reflected the (fixed part of) XML
structure the code expects to see and it made things much more obvious and self
documenting.

Don't remove it, improve it.

I don't think David was suggesting removing XML literals. At least, he uses them all the time in Lift.

--j

On Tue, May 12, 2009 at 5:20 PM, Ivan Todoroski <grnch_lists@gmx.net> wrote:

David Pollak <feeder.of.the.bears@...> writes:
> I do not use pattern matching with XML literals.  The whole extraction, etc.
> stuff is very, very difficult to get right.  I'd be in favor of removing XML
> pattern matching from the language.  Matching against Elem, etc. does just
> fine.

You can't be serious!

The XML literals and pattern matching have got to be one of the hottest
features of the language, yet you want them removed because you don't use them?
Those were the very things that made me pause and take a second look at Scala.

You may think this is shallow, but when explaining the benefits of Scala to a
busy and tired Java developer, you don't have much time to talk about the rich
type system, type inference, infix method syntax, first-class functions and how
it all clicks together, before the window of interest is lost.

Why should they care about Scala specifically, when there are lots of other
powerful languages competing for their attention, like Ruby, Python, Groovy,
Erlang, Clojure, Self, Nice, OCaml, Haskel, Io, F# and who knows what else.

On the other hand, when showing the XML literal syntax to DOM-weary Java
developers, they raise their eyebrow, and when you show them the complementary
XML pattern matching, their eyes positively light up. Then you explain that
it's syntactic sugar for matching a bunch of nested classes, that it can match
your own classes too, and they slowly start to realize the power behind the
Scala language, and that maybe they should invest some effort to learn about it
instead of some other language.

XML literals and patterns are like a left-right punch that makes people wake up
and pay attention. Without them it would be difficult to get your foot in the
door, so to speak.

Sure, XML patterns have some problems, I am not disputing that. I will also
grant that I may not use them everytime and everywhere, but in those place that
I did use them, I found that the pattern reflected the (fixed part of) XML
structure the code expects to see and it made things much more obvious and self
documenting.

Don't remove it, improve it.

Oh, I realize that, I only mentioned XML literals because they
*together* with XML patterns made me sit up and take notice, and it's
been the same thing with all my Java developer friends to whom I have
tried to demonstrate Scala so far. I don't think it would have been
nearly the same effect with XML literals alone (after all, there are
other languages that have XML literals as well, e.g. E4X, VB9).

Please, please, please don't remove XML patterns! :)

On 13.05.2009 09:21, Jorge Ortiz wrote:
> I don't think David was suggesting removing XML literals. At least, he
> uses them all the time in Lift.
>
> --j
>
> On Tue, May 12, 2009 at 5:20 PM, Ivan Todoroski > wrote:
>
> David Pollak writes:
> > I do not use pattern matching with XML literals. The whole
> extraction, etc.
> > stuff is very, very difficult to get right. I'd be in favor of
> removing XML
> > pattern matching from the language. Matching against Elem, etc.
> does just
> > fine.
>
> You can't be serious!
>
> The XML literals and pattern matching have got to be one of the hottest
> features of the language, yet you want them removed because you
> don't use them?
> Those were the very things that made me pause and take a second look
> at Scala.
>
> You may think this is shallow, but when explaining the benefits of
> Scala to a
> busy and tired Java developer, you don't have much time to talk
> about the rich
> type system, type inference, infix method syntax, first-class
> functions and how
> it all clicks together, before the window of interest is lost.
>
> Why should they care about Scala specifically, when there are lots
> of other
> powerful languages competing for their attention, like Ruby, Python,
> Groovy,
> Erlang, Clojure, Self, Nice, OCaml, Haskel, Io, F# and who knows
> what else.
>
> On the other hand, when showing the XML literal syntax to DOM-weary Java
> developers, they raise their eyebrow, and when you show them the
> complementary
> XML pattern matching, their eyes positively light up. Then you
> explain that
> it's syntactic sugar for matching a bunch of nested classes, that it
> can match
> your own classes too, and they slowly start to realize the power
> behind the
> Scala language, and that maybe they should invest some effort to
> learn about it
> instead of some other language.
>
> XML literals and patterns are like a left-right punch that makes
> people wake up
> and pay attention. Without them it would be difficult to get your
> foot in the
> door, so to speak.
>
> Sure, XML patterns have some problems, I am not disputing that. I
> will also
> grant that I may not use them everytime and everywhere, but in those
> place that
> I did use them, I found that the pattern reflected the (fixed part
> of) XML
> structure the code expects to see and it made things much more
> obvious and self
> documenting.
>
> Don't remove it, improve it.
>
>
>

On Wed, May 13, 2009 at 2:04 AM, Ivan Todoroski <grnch_lists@gmx.net> wrote:

Oh, I realize that, I only mentioned XML literals because they *together* with XML patterns made me sit up and take notice, and it's been the same thing with all my Java developer friends to whom I have tried to demonstrate Scala so far. I don't think it would have been nearly the same effect with XML literals alone (after all, there are other languages that have XML literals as well, e.g. E4X, VB9).

I think Scala's XML literals are great and I use them all the time.  I would never advocate removal from the language, in fact I have advocated for keeping them part of the language.

I have made pretty extensive use of XML pattern matching, but in Lift and in other apps I've built.  I've also done code reviews of a fair number of Scala programs over the years.  While I agree that XML pattern matching gives "great demo", in production use, they offer little value.  Beyond the issues that Paul outlined in the original post, there are the issues of extracting attributes, testing attributes, etc.  I've found that in every case, XML literal pattern matching very quickly devolves into custom extractors (unapply) and lots of guards.  So, while I am a huge fan of stuff that "demos well", I always like to make sure my demos reflect what can really be done with the language at scale and XML literal pattern matching does not scale into production and I can't figure out a way to make it do so.

As to the language attention issue, there are plenty of other Scala language features that set it appart from those on your list (running on the JVM for starters, statically typed, high performance, and concise code).
 

Please, please, please don't remove XML patterns! :)


On 13.05.2009 09:21, Jorge Ortiz wrote:

I don't think David was suggesting removing XML literals. At least, he uses them all the time in Lift.

--j

On Tue, May 12, 2009 at 5:20 PM, Ivan Todoroski <grnch_lists@gmx.net <mailto:grnch_lists@gmx.net>> wrote:

   David Pollak <feeder.of.the.bears@...> writes:
    > I do not use pattern matching with XML literals.  The whole
   extraction, etc.
    > stuff is very, very difficult to get right.  I'd be in favor of
   removing XML
    > pattern matching from the language.  Matching against Elem, etc.
   does just
    > fine.

   You can't be serious!

   The XML literals and pattern matching have got to be one of the hottest
   features of the language, yet you want them removed because you
   don't use them?
   Those were the very things that made me pause and take a second look
   at Scala.

   You may think this is shallow, but when explaining the benefits of
   Scala to a
   busy and tired Java developer, you don't have much time to talk
   about the rich
   type system, type inference, infix method syntax, first-class
   functions and how
   it all clicks together, before the window of interest is lost.

   Why should they care about Scala specifically, when there are lots
   of other
   powerful languages competing for their attention, like Ruby, Python,
   Groovy,
   Erlang, Clojure, Self, Nice, OCaml, Haskel, Io, F# and who knows
   what else.

   On the other hand, when showing the XML literal syntax to DOM-weary Java
   developers, they raise their eyebrow, and when you show them the
   complementary
   XML pattern matching, their eyes positively light up. Then you
   explain that
   it's syntactic sugar for matching a bunch of nested classes, that it
   can match
   your own classes too, and they slowly start to realize the power
   behind the
   Scala language, and that maybe they should invest some effort to
   learn about it
   instead of some other language.

   XML literals and patterns are like a left-right punch that makes
   people wake up
   and pay attention. Without them it would be difficult to get your
   foot in the
   door, so to speak.

   Sure, XML patterns have some problems, I am not disputing that. I
   will also
   grant that I may not use them everytime and everywhere, but in those
   place that
   I did use them, I found that the pattern reflected the (fixed part
   of) XML
   structure the code expects to see and it made things much more
   obvious and self
   documenting.

   Don't remove it, improve it.

--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp

On Wednesday May 13 2009, David Pollak wrote:
> ...
>
> I think Scala's XML literals are great and I use them all the time.
> I would never advocate removal from the language, in fact I have
> advocated for keeping them part of the language.

Am I the only one who sees XML literals as an voluminous and egregious
form of magic number?

> I have made pretty extensive use of XML pattern matching, but in Lift
> and in other apps I've built. I've also done code reviews of a fair
> number of Scala programs over the years. While I agree that XML
> pattern matching gives "great demo", in production use, they offer
> little value. Beyond the issues that Paul outlined in the original
> post, there are the issues of extracting attributes, testing
> attributes, etc. I've found that in every case, XML literal pattern
> matching very quickly devolves into custom extractors (unapply) and
> lots of guards. So, while I am a huge fan of stuff that "demos
> well", I always like to make sure my demos reflect what can really be
> done with the language at scale and XML literal pattern matching does
> not scale into production and I can't figure out a way to make it do
> so.

What would be nice is to get Scala pattern matching up to the level of
tree regular expressions or something similar, á là RELAX NG.

> ...

Randall Schulz

On 13.05.2009 15:22, David Pollak wrote:
> I have made pretty extensive use of XML pattern matching, but in Lift
> and in other apps I've built. I've also done code reviews of a fair
> number of Scala programs over the years. While I agree that XML pattern
> matching gives "great demo", in production use, they offer little
> value. Beyond the issues that Paul outlined in the original post, there
> are the issues of extracting attributes, testing attributes, etc. I've
> found that in every case, XML literal pattern matching very quickly
> devolves into custom extractors (unapply) and lots of guards. So, while
> I am a huge fan of stuff that "demos well", I always like to make sure
> my demos reflect what can really be done with the language at scale and
> XML literal pattern matching does not scale into production and I can't
> figure out a way to make it do so.

I understand what you are saying and agree about the current
limitations. But isn't it perhaps just a matter of implementation
maturity? I would argue that it's better to try and improve the XML
patterns, rather than excise them outright from the language.

> As to the language attention issue, there are plenty of other Scala
> language features that set it appart from those on your list (running on
> the JVM for starters, statically typed, high performance, and concise code).

I agree that these are advantages of Scala, but tn order to appreciate
those advantages (which are not all obvious [1]), one has to be hooked
in long enough to perceive them fully.

I would say the XML pattern matching is a pretty strong hook that
attracts developers to this language long enough to get to know it better.

And the more developers you attract this way, the higher the chance that
some of them may like XML patterns so much that they improve them and
submit patches. ;)

So keeping a "demoable" feature may prove to be a net win, even if it
may not be so useful at a larger scale (yet!).

[1] Why the Scala advantages you listed are not so strikingly obvious:

* Ruby, Python, Groovy, Clojure, Nice and probably some others also have
implementations that run on the JVM and have various degrees of integration.

* Someone new to Scala might view static typing as a disadvantage due to
the current hype generated over dynamically typed languages. It would
take some time to realize just how powerful and flexible Scala's typing
system is, to the point that you don't really need the main features of
dynamically typed languages.

* Performance varies among other languages, some are worse, some are
better, so here Scala may have the edge, but it is not easily demoable
or impressive.

* Most of the other languages also have conciseness as a stated goal.

I'm sure one could pick holes in all these languages, but the fact is it
requires mental effort and hence the Scala advantage is not so visible
at first, i.e. these advantages of Scala don't slap you in the face
quite as sharply as XML patterns.

I am speaking from personal experience, as well as the experience of
some friends and colleagues when they exposed me or were exposed by me
to Scala.

On 13.05.2009 15:49, Randall R Schulz wrote:
> Am I the only one who sees XML literals as an voluminous and egregious
> form of magic number?

I see them only as shorthand for a bunch of nested Elem classes, nothing
more, nothing less.

If you replaced them with a nested Elem invocation, you would end up
with an even more verbose magic number, yet nobody is using this to
justify removing the Elem class hierarchy.

You can hardcode stuff in any language, and any feature can be abused in
"magic numberish" ways...

> What would be nice is to get Scala pattern matching up to the level of
> tree regular expressions or something similar, á là RELAX NG.

Oh, this would be awesome. And then we could make an XML shorthand
notation for it! :)

I like XML literals and I like the idea of using them for pattern
matching. The reality is that pattern matching them is too sensitive
to whitespace. I'd like to see that improved.

What I especially like is that all the time I didn't give a monkey's
about XML, I didn't have to see any in Scala. It's a very unintrusive
language feature.

I would rather have a general technique for defining literal syntax
than something just for XML, but I'll take what we've got.

2009/5/13 Ivan Todoroski :
> On 13.05.2009 15:49, Randall R Schulz wrote:
>>
>> Am I the only one who sees XML literals as an voluminous and egregious
>> form of magic number?
>
> I see them only as shorthand for a bunch of nested Elem classes, nothing
> more, nothing less.
>
> If you replaced them with a nested Elem invocation, you would end up with an
> even more verbose magic number, yet nobody is using this to justify removing
> the Elem class hierarchy.
>
> You can hardcode stuff in any language, and any feature can be abused in
> "magic numberish" ways...
>
>> What would be nice is to get Scala pattern matching up to the level of
>> tree regular expressions or something similar, á là RELAX NG.
>
> Oh, this would be awesome. And then we could make an XML shorthand notation
> for it! :)
>
>