[
Lists Home |
Date Index |
Thread Index
]
Let me add Gavin and Erik (who are some of the guys I meant) to the thread to correct me if I am wrong and to counter my personal opinion :-).
First X#/Xen was basically one research project (not in MSR though :-)) that looked at building a tighter integration of XML querying and manipulation into a programming language (somewhat in the tradition of DB-PL integrations). It provided integration on the type level and some declarative aspects (and got extended later with the tuple aspects).
C-omega combined that with the concurrency aspect when the project moved into MSR.
Indeed the main goal is to merge the type systems to a level that you can operate on the "atomic" type instances using a common language framework (in this case a slightly extended C#) instead of inventing a different language that then needs to be embedded.
My personal opinion is that this is an interesting direction, with the advantage of closing the language/model impedance mismatch between the programming language users and the data query languages and providing better composability of the resulting language than embedding it. However, it also has its problems and pitfalls since it cannot get rid of the non-declarative aspects of the original language while still wanting to provide some declarative subset for optimizability. That's btw, why the APL extensions that Whitney has been working on (or chosing another functional language) have it somewhat easier since APL is closer to a functional, declarative language (once you remove the ->).
Best regards
Michael
> -----Original Message-----
> From: M. David Peterson [mailto:m.david.x2x2x@gmail.com]
> Sent: Friday, December 31, 2004 2:34 AM
> To: Michael Rys
> Cc: Uche Ogbuji; Daniela Florescu; Alan Gutierrez; Kevin Jones; xml-
> dev@lists.xml.org
> Subject: Re: [xml-dev] Streaming XML (WAS: More on taming SAX (was
> Re:[xml-dev] ANN: Amara XML Toolkit 0.9.0))
>
> Hi Michael,
>
> From your post:
>
> "The guys behind Xen and C-Omega are..."
>
> If interpreted without any knowledge that X#, Xen, and COmega were at
> one point there own very separate projects (or were they?) then this
> statement suggests/states that in the case of Xen and C-Omega in some
> form or another they still are.
>
> To try and put an end to my own misunderstandings as to "what is what"
> and "why" I recently took on a 5 minute research project at the
> MS-Research site and discovered what I think clarifiies more or less
> what is implied in your above statement. Would you mind taking a
> second to either validate or encourage further research (possible
> links?) so that I can once and for all get these two/three projects
> properly defined within my head and as such correct and proper
> information passed to any readers of future posts to my various
> blogs/sites in regards to these projects?
>
> All of this was found at t the main entry page into the COmega project
> site under the MS Research umbrella >
> http://research.microsoft.com/Comega/ <
>
> <blockquote>"C&ohgr; is an extension of C# in two areas:
>
> - A control flow extension for asynchronous wide-area concurrency
> (formerly known as Polyphonic C#):
>
> links snipped for space...
>
> - A data type extension for XML and table manipulation (formerly known
> as Xen and as X#):
>
> links snipped for space....
>
> Reasons why these kinds of extensions (and possibly more) are related,
> are described in this talk:
>
> * Transitions in Programming Models. Luca Cardelli.
> o [ <a
> href="http://research.microsoft.com/Users/luca/Slides/2003-11-
> 13%20Transitions%20in%20Programming%20Models%20(Lisbon).pdf">
> PDF</a> ] New University of Lisbon, November 13, 2003.</blockquote>
>
> After skimming through "Transitions in Programming Models" by Luca
> Cardelli it seems that the main, driving reason behind this is that
> the incompatible nature of the DSL langues being pulled into a much
> larger master language basically requires things to remain separate
> until such time that these incosistencies no longer exist and as such
> can be considered as a direct DSL type extension that has been
> natively and completely integrated as a first class data type made
> available via the proper mechanism
>
> So am I anywhewre near the target or do I need to dig deepers?
>
> Thanks in advance Michael!!!
>
> <M:D/>
>
>
>
> On Fri, 31 Dec 2004 00:09:55 -0800, Michael Rys <mrys@microsoft.com>
> wrote:
> > Uche
> >
> > I have nothing against Python (and only little against Java :-)), but
> > one reason that you cannot just use any language that happens to have an
> > XPath() function is composability of the type system and language.
> >
> > If you extend your type system to include all the XSD types and XML node
> > types, and make the language composable with your XPath expressions, you
> > will end up either with a new language that is inspired by your
> > language, but for a new user will have similar complexity to learn as,
> > for example, XQuery (70% of which is part of XPath 2.0 as well), or a
> > mess. The only people that will have it simpler are the ones that
> > already know a bit about your original language.
> >
> > Since the W3C due to its make-up cannot decide to just use SQL, Python,
> > APL, C# or Java as its basis for the XML Query language, it decided to
> > build XQuery to provide the composability.
> >
> > If you decide that you want evolve Python or another language that way,
> > feel free to do so. The guys behind Xen and C-Omega are looking at this,
> > as are others (and there used to be a similar approach to embed SQL, for
> > some better examples, see Arthur Whitney's work).
> >
> > Once you have done that, you just created a new language that will
> > compete with XQuery/XSLT etc that may have some advantages in some
> > circumstances but will in the end be just another one.
> >
> > If OTOH, you are fine with the limited composability since it covers the
> > 80% use cases for you and the language is declarative (Java or C#
> > current iterators are not), then you are of course correct that the
> > syntax does not make much of a difference.
> >
> > But then I think Dana would agree. Note that the discussion was about
> > using low-level processing APIs and not calling an XPATH() processor
> > within a declarative iterator...
> >
> > Best regards
> > Michael
> >
> > PS: I assume that you would choose the iterator's semantics to be
> > declarative and not procedural...
> >
> > > -----Original Message-----
> > > From: Uche Ogbuji [mailto:Uche.Ogbuji@fourthought.com]
> > > Sent: Thursday, December 30, 2004 11:44 AM
> > > To: Daniela Florescu
> > > Cc: Alan Gutierrez; Kevin Jones; xml-dev@lists.xml.org
> > > Subject: Re: [xml-dev] Streaming XML (WAS: More on taming SAX (was
> > > Re:[xml-dev] ANN: Amara XML Toolkit 0.9.0))
> > >
> > > On Mon, 2004-12-27 at 13:31 -0800, Daniela Florescu wrote:
> > > > > I've gotten pretty good at assembling a SAX engine quickly by
> > > > > composing one using resuable strategies.
> > > >
> > > > Alan,
> > > >
> > > > you didn't answer my question. Besides the personal
> > > > interest and fun, where there any technical reasons why
> > > > Xquery/XSLT wouldn't have been the right choice ?
> > > >
> > > > Instead of writing Java over SAX, isn't it more convenient
> > > > to write:
> > > >
> > > > for $x in //foobar
> > > > where some:predicate($x)
> > > > return my:function($x)
> > >
> > > I'd rather write
> > >
> > > [ myfunction(x) for x in root.xpath('//foobar') if somepredicate(x) ]
> > >
> > > This works *as is* today in Amara toolkit, and is pretty efficient.
> > >
> > > So why would I (or you) expect the Python developer to have to learn
> > > some complex, entirely new programming language to achieve the same
> > > goal?
> > >
> > > > and leave the smart streaming strategies to implementors
> > > > to figure out ?
> > >
> > > There are smart strategists implementing systems other than XQuery,
> > you
> > > know.
> > >
> > > > Did you try XQuery/XSLT and fail ? If yes, where did they
> > > > fell short ?
> > >
> > > I'd rather ask you, where there areas where all the many native XML
> > > processing facilities failed for you, when you decided to develop
> > > XQuery?
> > >
> > > Python and Java came before XQuery, so I don't see why they have to be
> > > the ones to justify themselves.
> > >
> > >
> > > --
> > > Uche Ogbuji Fourthought, Inc.
> > > http://uche.ogbuji.net http://4Suite.org http://fourthought.com
> > > Use CSS to display XML - http://www.ibm.com/developerworks/edu/x-dw-x-
> > > xmlcss-i.html
> > > Full XML Indexes with Gnosis - http://www.xml.com/pub/a/2004/12/08/py-
> > > xml.html
> > > Be humble, not imperial (in design) -
> > > http://www.adtmag.com/article.asp?id=10286
> > > UBL 1.0 -
> > http://www-106.ibm.com/developerworks/xml/library/x-think28.html
> > > Use Universal Feed Parser to tame RSS -
> > > http://www.ibm.com/developerworks/xml/library/x-tipufp.html
> > > Default and error handling in XSLT lookup tables -
> > > http://www.ibm.com/developerworks/xml/library/x-tiplook.html
> > > A survey of XML standards - http://www-
> > > 106.ibm.com/developerworks/xml/library/x-stand4/
> > > The State of Python-XML in 2004 -
> > http://www.xml.com/pub/a/2004/10/13/py-
> > > xml.html
> > >
> > >
> > > -----------------------------------------------------------------
> > > The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> > > initiative of OASIS <http://www.oasis-open.org>
> > >
> > > The list archives are at http://lists.xml.org/archives/xml-dev/
> > >
> > > To subscribe or unsubscribe from this list use the subscription
> > > manager: <http://www.oasis-open.org/mlmanage/index.php>
> >
> > -----------------------------------------------------------------
> > The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> > initiative of OASIS <http://www.oasis-open.org>
> >
> > The list archives are at http://lists.xml.org/archives/xml-dev/
> >
> > To subscribe or unsubscribe from this list use the subscription
> > manager: <http://www.oasis-open.org/mlmanage/index.php>
> >
> >
>
>
> --
> :: M. David Peterson ::
> XML & XML Transformations, C#, .NET, and Functional Languages Specialist
|
