[
Lists Home |
Date Index |
Thread Index
]
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ω 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
|
