This page is no longer maintained — Please continue to the home page at

Re: Putting the cart before the horse?

1 reply
Alex Cruise
Joined: 2008-12-17,
User offline. Last seen 2 years 26 weeks ago.
I don't have the source tree handy now, but basically you create foo.scala as an object with a main method in test/files/jvm, have it output to stdout, and create foo.check containing the expected output beside it. Partest will compile, run and compare.

IIRC. :)


----- Reply message -----
From: "Anthony B. Coates (Londata)" <abcoates [at] londata [dot] com>
Date: Sat, Dec 12, 2009 9:02 AM
Subject: [scala-xml] Putting the cart before the horse?
To: <scala-xml [at] listes [dot] epfl [dot] ch>

Replies below:

On Sat, 12 Dec 2009 16:50:50 -0000, Mark Howe <mark [at] cyberporte [dot] com> wrote:

>> However, instead of the SAX API, it
>> might be better to try the StAX API instead, and derive something from
>> that
> Looks plausible to me at a quick glance. Is there a StAX reference
> manual or spec somewhere? Or a decent book? It's not the greatest of
> words to google.

Sorry, StAX is the old name. It's part of Java 6 now, the
'' package:

>> Since namespace handling has been brought into
>> question with the current parser, it would be good to set up some tests
>> to
>> know for sure.
> That would be great! The cryptic aside documenting of this behaviour
> suggests that the test needs to look specifically at serialisation. It
> sounds like the namespace information is read in correctly, but is not
> used systematically when the tree is serialised.

OK, I'm glad you pointed that out specifically. I must say, I'm still
struggling to understand how 'partest' works, and what is the right have
to write tests for the Scala source tree, so if you can give me any
pointers, I would be really grateful. Thanks,

Cheers, Tony.
Anthony B. Coates
Director and CTO
Londata Ltd
abcoates [at] londata [dot] com
UK: +44 (20) 8816 7700, US: +1 (239) 344 7700
Mobile/Cell: +44 (79) 0543 9026
Skype: abcoates
Data standards participant: genericode, ISO 20022 (ISO 15022 XML),
Alex Cruise
Joined: 2008-12-17,
User offline. Last seen 2 years 26 weeks ago.
Re: Putting the cart before the horse?
Thanks Greg,

I've already experienced the benefits of declarative binding between syntax/XML and model/POJO via JAXB; I guess what I was fishing for, but unable to ask for in a concise way, was how, in your opinion, a desire to make use of such binding approaches should influence the design of the node object model, parsers, serializers, etc.

I don't see how the binding support needs to be anything more than a layer over the basic XML syntax libraries, rather than needing any tighter coupling. But not seeing what's right in front if my face is something of a talent of mine, so who's to say? :)

And my suggestion to defer spending a lot of time discussing it was based simply on a desire to try to get everyone's attention focused on ensuring that that lowest layer be as reliable, coherent and simple as possible.

Believe me, I'm a lot more excited by the higher-level, semantic use cases than the syntactic basics, but I don't believe it will be possible to achieve the former without the latter.

Thanks again for engaging with this sausage factory. :)

-0xe1a----- Reply message -----
From: "Meredith Gregory" <lgreg [dot] meredith [at] gmail [dot] com>
Date: Sun, Dec 13, 2009 2:41 PM
Subject: [scala-xml] Putting the cart before the horse?
To: <scala-xml [at] listes [dot] epfl [dot] ch>

Dear Alex,
Since you asked i will do that. i'm out of time on this for today, but will get you a small sample, tomorrow. In the meantime, on the OCamlDuce site i found both an atomrss reader sample and an aaxl (the xml verison of aadl). If you can read Scala and whenever you see in OCaml 'let ptn = expr'  you think 'val ptn = expr' you ought to be able to transliterate in your head (ok, that might be a slight exaggeration...). Beyond that, reconsider my example
<complexType name="Point">   <complexContent>      <sequence>          <element name="x" type="float"/>         <element name="y" type="float"/>       </sequence>   </complexContent></complexType>
ought to map to
case class Point( x : Float, y : Float )
And then you ought to have the following verifiable property, (sprinkle quantifiers as needed)
{ ( x : Float, y : Float ) =>   { validate( serialize( Point( x, y ) ), "Point.xsd" ) == true } } // The fact that this function must return true for all x and y in Float says that validation coincides with typing
as well as the verifiable property
{ if ( validate( "point.xml", "Point.xsd" ) ) {     deserialize( "point.xml" ).isInstanceOf[Point] == true } } // The fact that whenever the test is true the true branch always returns true says typing coincides with validation
This will allow someone to write things like
deserialize( "point.xml" ) match {    case Point( x, y ) => sqrt( x*x + y*y )}
And the fact that it compiles will mostly do away with the need for runtime validation. Again, if people want a different schema language, you can achieve this in several ways, including:
  • JAXB supports multiple schema languages, including RelaxNG (i think);
  • Trang -- put out by RelaxNG's author -- supports schema conversion, as does Oxygen.

But, take this example and recast it in the existing framework. Someone has to build by hand the case class and then someone has to build by hand the serialization/deserialization mechanism for Point. That's repetitious and error-prone and no-one gets any support from the type system. Their deserialization mechanism could completely subvert typing, for example, which would be a mistake. If you want to convert to a different type -- say from Point to Vector -- then keeping track of the conversion *with types* is important for many reasons.
Best wishes,

On Sun, Dec 13, 2009 at 1:44 PM, Alex Cruise <alex [at] cluonflux [dot] com> wrote:
Meredith Gregory wrote:
If one works with these biases, instead of against them, which are in turn aligned with much deeper principles, then the way is paved for much greater productivity and use cases that we have not yet discussed. Continued work at the merely syntactic level will serve to limit ScalaXML usability -- which i find sad -- especially since
   * CDuce/OCamlDuce was much further along than ScalaXML as early as
     2005, and it was done by just 1 guy (btw, has anyone in this
     thread, besides myself, actually looked at these language
     offerings? Scala's design as a language owes a great deal to OCaml.)


I sincerely wish I was able to intuitively grasp your point, and I feel like we would be well served by giving serious consideration to your advice, but I lack the experience in reading OCaml and/or the intelligence to fully understand what I'm looking at.  I'm loath to add to your workload, but maybe if you could distill what you feel to be the central contributions of OCamlDuce, and produce a quick sketch of what some analogous Scala library/language features might look like, I know it would help me (and, I suspect, others) a great deal.



L.G. Meredith
Managing Partner
Biosimilarity LLC
1219 NW 83rd St
Seattle, WA 98117

+1 206.650.3740

Copyright © 2012 École Polytechnique Fédérale de Lausanne (EPFL), Lausanne, Switzerland