www.digitalmars.com         C & C++   DMDScript  

D - DML redux

reply "J. Daniel Smith" <j_daniel_smith HoTMaiL.com> writes:
Last summer, there was some discussion here about DML - D expressed as XML;
see http://jdanielsmith.org/DML for a few very simple samples.

Now, the March 2003 issue of DDJ (http://www.ddj.com/articles/2003/0303/)
has an article that discusses the same basic idea (of course it isn't
specific to D).  "Sooner or later, programmers will solve both problems
[JSP/JavaDoc/etc. issues] by abandoning flat text and storing programs as
XML documents."  The article cites a language called Superx++
(http://xplusplus.sourceforge.net/index.htm) which claims to be "first
object-oriented language based on XML".

   Dan
Feb 14 2003
parent reply Ilya Minkov <midiclub 8ung.at> writes:
Have a look at x++ - it's really lengthy and clumnsy. As a contrast, 
there is a C-like alternative syntax for it, shortx, which is *much* 
better for writing general-purpose code.

But XML syntax makes sense for x++, since it's a special domain, 
text-processing language. All of x++ objects are repersented as XML text 
internally, so that it really makes sense that whenever you need XML as 
output, you'd also be programming in the terms of it. One thing less to 
consider. However, when classes don't need to be output, or output 
doesn't have to match particular constructs, a more legible syntax 
certainly makes more sense.

An example of XML use which makes sense, is processing XHTML. You simply 
write some objects which match XHTML constructs, in basically the same 
language, and then you can readily read them in from XHTML source, or 
output them to text and they would form another legal XHTML document. 
However, i don't see a possibility of such use in D.

It's however possible to define interpreted sub-languages within D as 
libraries. One example of how this is done is the regexp library. 
Extensions like compiled constant data and dynamic code generation might 
bring this much further than "normal" interpreted languages allow.

I have taken a look at your proposal. It has a completely different 
sense. Yes, it does have some rationale, but... do you expect someone to 
read or write D as XML? It's impossible. XML is merely a transport and a 
transformation framework. To use it:
  - an editor must support writing code in a normal manner, generating 
XML in background;
  - a convertor must exist to convert existing code;
  - there really has to be more use to it than generating HTML and D, as 
this is accompished with current means. I can imagine some, like code 
processing tools could be simplified. (Maybe.)

I'd rather say that even the current HTML stripper need not necessarily 
be a part of compiler, since it's a simple text-level procesing, it 
might work just as well as external program. It even draws much less 
speed benefit than XML would from integration. A compiler driver can be 
written to make it all natural to the user. If the feature finds use, it 
can be built into the compiler.

-i.




J. Daniel Smith wrote:

 Last summer, there was some discussion here about DML - D expressed as XML;
 see http://jdanielsmith.org/DML for a few very simple samples.
 
 Now, the March 2003 issue of DDJ (http://www.ddj.com/articles/2003/0303/)
 has an article that discusses the same basic idea (of course it isn't
 specific to D).  "Sooner or later, programmers will solve both problems
 [JSP/JavaDoc/etc. issues] by abandoning flat text and storing programs as
 XML documents."  The article cites a language called Superx++
 (http://xplusplus.sourceforge.net/index.htm) which claims to be "first
 object-oriented language based on XML".
 
    Dan
Feb 14 2003
next sibling parent "J. Daniel Smith" <j_daniel_smith HoTMaiL.com> writes:
The DDJ article does a much better job of expressing the general idea than
my very simple DML example.

As with Superx++, the input to the compiler would be XML.  Of course, you
really wouldn't type in such XML - it's much too difficult.  Rather, an IDE
would let you type in the D syntax and behind the scenes it would convert it
to XML.

The DDJ article points out (unfortunately, it's not on-line right now) that
once you have things in XML, you have a whole toolchest of utilites that you
can use on your source code.  The comparision is made to the traditional
UNIX text processing utilties (sed/awk/grep/etc.) that work so well on files
formatted as "lines of text".  Currently, to do any non-trivial
manipulation/examination of D source code, you have to use a special D
parser; the idea with DML is that rather than having specialized tools that
understand D syntax, you're able to use the general XML tools (XSLT, XPath,
etc.).

I used the HTML stripper currently in D as a way to get people thinking
about other possibilities.

   Dan

"Ilya Minkov" <midiclub 8ung.at> wrote in message
news:b2jema$c12$1 digitaldaemon.com...

 Have a look at x++ - it's really lengthy and clumnsy. As a contrast,
 there is a C-like alternative syntax for it, shortx, which is *much*
 better for writing general-purpose code.

 But XML syntax makes sense for x++, since it's a special domain,
 text-processing language. All of x++ objects are repersented as XML text
 internally, so that it really makes sense that whenever you need XML as
 output, you'd also be programming in the terms of it. One thing less to
 consider. However, when classes don't need to be output, or output
 doesn't have to match particular constructs, a more legible syntax
 certainly makes more sense.

 An example of XML use which makes sense, is processing XHTML. You simply
 write some objects which match XHTML constructs, in basically the same
 language, and then you can readily read them in from XHTML source, or
 output them to text and they would form another legal XHTML document.
 However, i don't see a possibility of such use in D.

 It's however possible to define interpreted sub-languages within D as
 libraries. One example of how this is done is the regexp library.
 Extensions like compiled constant data and dynamic code generation might
 bring this much further than "normal" interpreted languages allow.

 I have taken a look at your proposal. It has a completely different
 sense. Yes, it does have some rationale, but... do you expect someone to
 read or write D as XML? It's impossible. XML is merely a transport and a
 transformation framework. To use it:
   - an editor must support writing code in a normal manner, generating
 XML in background;
   - a convertor must exist to convert existing code;
   - there really has to be more use to it than generating HTML and D, as
 this is accompished with current means. I can imagine some, like code
 processing tools could be simplified. (Maybe.)

 I'd rather say that even the current HTML stripper need not necessarily
 be a part of compiler, since it's a simple text-level procesing, it
 might work just as well as external program. It even draws much less
 speed benefit than XML would from integration. A compiler driver can be
 written to make it all natural to the user. If the feature finds use, it
 can be built into the compiler.

 -i.




 J. Daniel Smith wrote:

 Last summer, there was some discussion here about DML - D expressed as




XML;

 see http://jdanielsmith.org/DML for a few very simple samples.

 Now, the March 2003 issue of DDJ




(http://www.ddj.com/articles/2003/0303/)

 has an article that discusses the same basic idea (of course it isn't
 specific to D).  "Sooner or later, programmers will solve both problems
 [JSP/JavaDoc/etc. issues] by abandoning flat text and storing programs




as

 XML documents."  The article cites a language called Superx++
 (http://xplusplus.sourceforge.net/index.htm) which claims to be "first
 object-oriented language based on XML".

    Dan
Feb 14 2003
prev sibling parent "Jeroen van Bemmel" <anonymous somewhere.com> writes:
 Have a look at x++ - it's really lengthy and clumnsy. As a contrast,
 there is a C-like alternative syntax for it, shortx, which is *much*
 better for writing general-purpose code.


Does anyone else also think this is kinda funny? I mean, "inventing" an XML
based OO language and then "inventing" a shorthand syntax for it? That's
like reinventing the wheel twice
Feb 15 2003