www.digitalmars.com         C & C++   DMDScript  

D - D in XML, some ideas

reply "OddesE" <OddesE_XYZ hotmail.com> writes:
I have been reading some threads on using D in combination with HTML and XML
with great interest. Basically the ideas for XML were pretty basic, and
Walter said that he did not know much about XML yet, but was interested. A
lot of people said that XML, well, sucked, because it isn't easily human
readable, but I would want these people and Walter to take a little while
looking at some web sites about XML, and this website about programming:

http://mindprod.com/scid.html

Because if you combine XML with the ideas that Roedy Green talks about on
that page, you might change your mind about XML. The longer I have been
thinking about the XML threads I read, the more it seemed to me that saving
in any other format than XML made little sense!
Here's why:

Friends I have always write codeblocks like this:

void Func(int iCount) {
    for (int i=0; i<iCount; i++) {
        printf ("Hello world.\n");
    }
}

But I prefer:

void Func(int iCount)
{
    for (int i=0; i<iCount; i++)
    {
        printf ("Hello world.\n");
    }
}
or maybe:

void Func(int iCount)
{
    for (int i=0; i<iCount; i++)
        printf ("Hello world.\n");
}

All of these examples produce exactly the same program. They represent
exactly the same data, they are only a different *view* on the data.
Shouldn't changing the type of indentation for all source files you ever
work with be as easy as changing one setting?

Source files for programming languages like Java, C/C++ or D are plain text
files, that contain both layout and data, something we learned from HTML
should be separated.
Now imagine that beneath the surface the IDE would save the code above in
XML like this:

<?xml version="1.0">
<Program>
    <Module name="main">
        <Function name="Func">
            <Return>void</Return>
            <Argument name="iCount">int</Argument>
            <CodeBlock>
                <For>
                    <ForInitializer>int i=0</ForInitializer>
                    <ForUpdater>i<iCount</ForUpdater>
                    <ForEvaluation>i<iCount</ForEvaluation>
                    <CodeBlock>
                        printf ("Hello world.\n");
                    </CodeBlock>
                </For>
            </CodeBlock>
        </Function>
    </Module>
</Program>

It looks very complex, but it contains the same information as the .d file.
Now it would be a breeze to change all kinds of layout settings to create
another .d file with exactly the same source code, but with a different
view on that source code.

All you would need to do is make a XML specification for D code.
You probably could find some people here on the newsgroup to deal with
most of making such a specification, you would only have to make sure it
was language compliant. Then everyone could use that spec to implement
a tool to convert .d files to .xml files. And from .xml files you can go
back
to .html, .pdf, .doc or indeed other .d files without having to write *any*
software. You would only need to write an XSL
stylesheet that containes the rules of making the conversion. All the .xml
parsing and translation software can then be used.

If I sound strange, check out that website I was referring to, and read
something about XML, I think it will get clear what I mean and you
will become enthousiastic about the idea.

The XML code above was typed right into outlook from the top of
my head and probably will contain errors. Also it is probably not a
very good way to do this, but it illustrates the point.
I think a good language designer who knows a little about XML
could very easily make a smart and structured specification for saving
D source code as XML code. I however am merely a humble
programmer without a clue of the internals of compilers.  :)
Read that web page, it will change the way you look at source code!


--
Stijn
OddesE_XYZ hotmail.com
http://www.OddesE.f2s.com
__________________________________________
Remove _XYZ from my address when replying by mail
Jan 17 2002
next sibling parent "Sean L. Palmer" <spalmer iname.com> writes:
This guy read my mind.  ;)

D certainly has an easier syntax for writing parsers for this kind of thing
than C++ does.

Sean

"OddesE" <OddesE_XYZ hotmail.com> wrote in message
news:a27qo9$11p3$1 digitaldaemon.com...
 I have been reading some threads on using D in combination with HTML and

 with great interest. Basically the ideas for XML were pretty basic, and
 Walter said that he did not know much about XML yet, but was interested. A
 lot of people said that XML, well, sucked, because it isn't easily human
 readable, but I would want these people and Walter to take a little while
 looking at some web sites about XML, and this website about programming:

 http://mindprod.com/scid.html

 Because if you combine XML with the ideas that Roedy Green talks about on
 that page, you might change your mind about XML. The longer I have been
 thinking about the XML threads I read, the more it seemed to me that

 in any other format than XML made little sense!
 Here's why:

 Friends I have always write codeblocks like this:

 void Func(int iCount) {
     for (int i=0; i<iCount; i++) {
         printf ("Hello world.\n");
     }
 }

 But I prefer:

 void Func(int iCount)
 {
     for (int i=0; i<iCount; i++)
     {
         printf ("Hello world.\n");
     }
 }
 or maybe:

 void Func(int iCount)
 {
     for (int i=0; i<iCount; i++)
         printf ("Hello world.\n");
 }

 All of these examples produce exactly the same program. They represent
 exactly the same data, they are only a different *view* on the data.
 Shouldn't changing the type of indentation for all source files you ever
 work with be as easy as changing one setting?

 Source files for programming languages like Java, C/C++ or D are plain

 files, that contain both layout and data, something we learned from HTML
 should be separated.
 Now imagine that beneath the surface the IDE would save the code above in
 XML like this:

 <?xml version="1.0">
 <Program>
     <Module name="main">
         <Function name="Func">
             <Return>void</Return>
             <Argument name="iCount">int</Argument>
             <CodeBlock>
                 <For>
                     <ForInitializer>int i=0</ForInitializer>
                     <ForUpdater>i<iCount</ForUpdater>
                     <ForEvaluation>i<iCount</ForEvaluation>
                     <CodeBlock>
                         printf ("Hello world.\n");
                     </CodeBlock>
                 </For>
             </CodeBlock>
         </Function>
     </Module>
 </Program>

 It looks very complex, but it contains the same information as the .d

 Now it would be a breeze to change all kinds of layout settings to create
 another .d file with exactly the same source code, but with a different
 view on that source code.

 All you would need to do is make a XML specification for D code.
 You probably could find some people here on the newsgroup to deal with
 most of making such a specification, you would only have to make sure it
 was language compliant. Then everyone could use that spec to implement
 a tool to convert .d files to .xml files. And from .xml files you can go
 back
 to .html, .pdf, .doc or indeed other .d files without having to write

 software. You would only need to write an XSL
 stylesheet that containes the rules of making the conversion. All the .xml
 parsing and translation software can then be used.

 If I sound strange, check out that website I was referring to, and read
 something about XML, I think it will get clear what I mean and you
 will become enthousiastic about the idea.

 The XML code above was typed right into outlook from the top of
 my head and probably will contain errors. Also it is probably not a
 very good way to do this, but it illustrates the point.
 I think a good language designer who knows a little about XML
 could very easily make a smart and structured specification for saving
 D source code as XML code. I however am merely a humble
 programmer without a clue of the internals of compilers.  :)
 Read that web page, it will change the way you look at source code!


 --
 Stijn
 OddesE_XYZ hotmail.com
 http://www.OddesE.f2s.com
 __________________________________________
 Remove _XYZ from my address when replying by mail

Jan 18 2002
prev sibling next sibling parent reply "Pavel Minayev" <evilone omen.ru> writes:
This is all great, but I tell you one thing. I'm never going
to type in program in XML, and I don't want to use a converter
each time I'm going to compile it as well. Yes, IDEs, all is
great - but on *NIX many people still use vi to edit files and
command-line to compile them - and they won't be happy of any
additional step that is to be introduced. XML could be _one_
of possible input formats for D, but definitely not the primary.

Also, one idea about all this. What if D compiler supports some
sort of "filters" - it feeds them the source code from the
file and then compiles their output. This way, an XML filter
could be easily written, as well as many others exotic formats;
HTML could be done as a filter as well...
Jan 18 2002
parent reply "OddesE" <OddesE_XYZ hotmail.com> writes:
"Pavel Minayev" <evilone omen.ru> wrote in message
news:a28v11$1pj1$1 digitaldaemon.com...
 This is all great, but I tell you one thing. I'm never going
 to type in program in XML, and I don't want to use a converter
 each time I'm going to compile it as well. Yes, IDEs, all is
 great - but on *NIX many people still use vi to edit files and
 command-line to compile them - and they won't be happy of any
 additional step that is to be introduced. XML could be _one_
 of possible input formats for D, but definitely not the primary.

 Also, one idea about all this. What if D compiler supports some
 sort of "filters" - it feeds them the source code from the
 file and then compiles their output. This way, an XML filter
 could be easily written, as well as many others exotic formats;
 HTML could be done as a filter as well...

Oh I definitely agree! I didn't mean to say you should *write* the code in XML! That would be undoable! :) XML is not really meant to be read, let alone written, by humans. It is a data representation format designed for computers. This is what I imagine: You type in your function in the editor, just like you would always do, using your own coding style, like this: void Func(int iCount) { for (int i=0; i<iCount; i++) { printf ("Hello world.\n"); } } To you there is absolutely *no* difference. The editor stores the file in memory in normal .d format until it is saved, at which time it saves it in .d or .xml format, whichever you prefer. Let's assume for the moment you choose .xml, although there isn't a single reason why saving in .d would be impossible or even difficult. When you run your program, the IDE sends plain .d code (no XML) to the compiler, which compiles it, after which it can be linked and run. No changes there either, the compiler stays exactly the same, no need for any special filters or anything. After you finish your work and close the IDE, the files are saved on your harddisk in .xml format. The next day you open the .xml files again and see your function like this: void Func(int iCount) { for (int i=0; i<iCount; i++) { printf ("Hello world.\n"); } } exactly the same! But now I come in. You decide you need another programmer for, say, maintenance coding, and you hire me for the job. I however, have my own coding style, and set my IDE to different settings, so when I load your .xml file containing the Func function, I see this: void Func (int iCount) { for (int i=0; i<iCount; i++) { printf ("Hello world.\n"); } } And, when it comes to the official documentation, written in say HTML, you would only need one .XSL stylesheet that defines the conversion, to produce .html files that all use exactly the same coding style and syntax coloring options. Better still, because the .xml files contain no information about style, just the pure code, changing the company style for all thousand programmers would be as easy as changing one XSL stylesheet and recreating the documentation files from the original .xml source code files. Every programmer in the organisation could use his own personal style, without having to compromise to the style of any other programmer, and the .xml files wouldn't change one bit! If you now think to yourself, this is too good to be true, and you have all kinds of objections for why this can't be possible or would be very impractical, let me try to address some of the first ones that came into my mind: - XML files are unreadble for humans: As described above, this should not be a problem, you should never have to read or write a single letter of XML. You code in D, like you always did. - XML files are too complex: Although .xml files indeed do look very complex to humans, to computers they are actually very easily parsable, they were intentionally designed that way. - I would have to choose between .xml and .d file formats: XML was designed with format conversions in mind. The conversion from .d to XML is specific to the D language, so you would need a tool, filter, plugin, component or whatever to do that, but conversion from XML to any other format, including HTML, PDF, DOC or just back to D again would only require writing a XSL stylesheet. There are standard XML parsers and conversion tools that can then do the conversion job. This means you could use saving as .d for years, then one day convert all these .d files to .xml in one large swoop and immediately gain all the benefits of .xml. It also works the other way around. You could save as .xml for years and then one day convert them all back to .d again. At no point in time would you ever be forced to choose between saving as .d or as .xml without a very simple way to reverse that choice. - I would need to write complex stylesheets: Most probably not. You *could* write your own stylesheet, but you probably would leave such tasks to the IDE or 3rd-party specialised tools. - To include the option of saving as XML would require an enormeous amount of work, special compilers and IDE's, and would overall be a threat to using D on different platforms: Definitely not. To include the option to save as .xml you would need: 1) A solid XML specification for translating D code to XML. 2) A tool to convert D code to XML according to that specification. 3) A tool to create custom stylesheets based on settings such as indentation type, tabs/versus spaces etc. 1) and 2) are vital, but the stylesheets could be written by hand in the beginning, and a few common ones with standard code style features could be placed on a website. Also, only the XML specification is time critical, because you could use D without XML just fine for as long as it would take for the D to XML conversion tools to be designed. Ofcourse the XML specification needs to be well defined before you can start building the conversion tool(s). Designing a solid XML specification for translating D code to XML wouldn't be easy, but it would be peanuts compared to designing a whole language and largely follows from the syntax and structure rules for D. It does need to be an 'official' specification, because if there would be many (slightly) different versions you would soon lose a lot of the big benefits of .xml. In that respect it is like a programming language, if everyone uses slightly different versions of a language, maintaining and porting code becomes difficult. And that's it. IDE's would only need one option more, Save As XML, which would send the .d code to the conversion tool which would then save it to disk as .xml. On loading a .xml file, they would send it to a standard XML transformation tool with the stylesheet the user wants and then the file would be loaded into memory in D format as always. Optionally the IDE would allow for code style settings to be saved to a stylesheet using the stylesheet creation tool. The compiler would not change at all. Because you are never forced to use .xml files and because a standard .d to .xml tool would be relatively easy to design for all platforms, and because .xml to .d conversions can be done with just a stylesheet and standard tools that already exist for all platforms, XML wouldn't be a threat to using D on multiple platforms at all. In the contrary! Sorry for the very long story, but I just *love* the idea! -- Stijn OddesE_XYZ hotmail.com http://OddesE.cjb.net __________________________________________ Remove _XYZ from my address when replying by mail
Jan 18 2002
parent reply "J. Daniel Smith" <j_daniel_smith deja.com> writes:
The only thing about this that I'd tweak is setting up the compiler to
accept the XML file directly.

1.  the D compiler already has support for "D in HTML", since it already
deals with a .htm file, it can deal with a .xml file too
2.  Given that the compiler already has a mechanism for converting .htm file
to D, adding support for a .xml file using a built-in XSLT stylesheet is
straightfoward.
3.  Most importantly, by the compiler supporting a particular "D in XML"
dialect, we avoid a bunch of different and incompatiable styles of XML.  (Of
course, with another XSLT tranform you can convert from one "D in XML"
dialect to another).

   Dan

"OddesE" <OddesE_XYZ hotmail.com> wrote in message
news:a29u9b$2ola$1 digitaldaemon.com...
 "Pavel Minayev" <evilone omen.ru> wrote in message
 news:a28v11$1pj1$1 digitaldaemon.com...
 This is all great, but I tell you one thing. I'm never going
 to type in program in XML, and I don't want to use a converter
 each time I'm going to compile it as well. Yes, IDEs, all is
 great - but on *NIX many people still use vi to edit files and
 command-line to compile them - and they won't be happy of any
 additional step that is to be introduced. XML could be _one_
 of possible input formats for D, but definitely not the primary.

 Also, one idea about all this. What if D compiler supports some
 sort of "filters" - it feeds them the source code from the
 file and then compiles their output. This way, an XML filter
 could be easily written, as well as many others exotic formats;
 HTML could be done as a filter as well...

Oh I definitely agree! I didn't mean to say you should *write* the code in XML! That would be undoable! :) XML is not really meant to be read, let alone written, by humans. It is a data representation format designed for computers. This is what I imagine: You type in your function in the editor, just like you would always do, using your own coding style, like this: void Func(int iCount) { for (int i=0; i<iCount; i++) { printf ("Hello world.\n"); } } To you there is absolutely *no* difference. The editor stores the file in memory in normal .d format until it is

 at which time it saves it in .d or .xml format, whichever you prefer.

 assume for the moment you choose .xml, although there isn't a single

 why saving in .d would be impossible or even difficult.
 When you run your program, the IDE sends plain .d code (no XML) to the
 compiler, which compiles it, after which it can be linked and run. No
 changes there either, the compiler stays exactly the same, no need for any
 special filters or anything.
 After you finish your work and close the IDE, the files are saved on your
 harddisk in .xml format. The next day you open the .xml files again and

 your function like this:

 void Func(int iCount) {
     for (int i=0; i<iCount; i++) {
         printf ("Hello world.\n");
     }
 }

 exactly the same!
 But now I come in. You decide you need another programmer for, say,
 maintenance coding, and you hire me for the job. I however, have my own
 coding style, and set my IDE to different settings, so when I load your

 file containing the Func function, I see this:

 void Func (int iCount)
 {
     for (int i=0; i<iCount; i++)
     {
         printf ("Hello world.\n");
     }
 }

 And, when it comes to the official documentation, written in say HTML, you
 would only need one .XSL stylesheet that defines the conversion, to

 .html files that all use exactly the same coding style and syntax coloring
 options. Better still, because the .xml files contain no information about
 style, just the pure code, changing the company style for all thousand
 programmers would be as easy as changing one XSL stylesheet and recreating
 the documentation files from the original .xml source code files. Every
 programmer in the organisation could use his own personal style, without
 having to compromise to the style of any other programmer, and the .xml
 files wouldn't change one bit!

 If you now think to yourself, this is too good to be true, and you have

 kinds of objections for why this can't be possible or would be very
 impractical, let me try to address some of the first ones that came into

 mind:

 - XML files are unreadble for humans:

 As described above, this should not be a problem, you should never have to
 read or write a single letter of XML. You code in D, like you always did.

 - XML files are too complex:

 Although .xml files indeed do look very complex to humans, to computers

 are actually very easily parsable, they were intentionally designed that
 way.

 - I would have to choose between .xml and .d file formats:

 XML was designed with format conversions in mind. The conversion from .d

 XML is specific to the D language, so you would need a tool, filter,

 component or whatever to do that, but conversion from XML to any other
 format, including HTML, PDF, DOC or just back to D again would only

 writing a XSL stylesheet. There are standard XML parsers and conversion
 tools that can then do the conversion job. This means you could use saving
 as .d for years, then one day convert all these .d files to .xml in one
 large swoop and immediately gain all the benefits of .xml. It also works

 other way around. You could save as .xml for years and then one day

 them all back to .d again. At no point in time would you ever be forced to
 choose between saving as .d or as .xml without a very simple way to

 that choice.

 - I would need to write complex stylesheets:

 Most probably not. You *could* write your own stylesheet, but you probably
 would leave such  tasks to the IDE or 3rd-party specialised tools.

 - To include the option of saving as XML would require an enormeous amount
 of work, special compilers and IDE's, and would overall be a threat to

 D on different platforms:

 Definitely not.
 To include the option to save as .xml you would need:
 1) A solid XML specification for translating D code to XML.
 2) A tool to convert D code to XML according to that specification.
 3) A tool to create custom stylesheets based on settings such as

 type,
 tabs/versus spaces etc.

 1) and 2) are vital, but the stylesheets could be written by hand in the
 beginning, and a few common ones with standard code style features could

 placed on a website.
 Also, only the XML specification is time critical, because you could use D
 without XML just fine for as long as it would take for the D to XML
 conversion tools to be designed. Ofcourse the XML specification needs to

 well defined before you can start building the conversion tool(s).
 Designing a solid XML specification for translating D code to XML wouldn't
 be easy, but it would be peanuts compared to designing a whole language

 largely follows from the syntax and structure rules for D. It does need to
 be an 'official' specification, because if there would be many (slightly)
 different versions you would soon lose a lot of the big benefits of .xml.

 that respect it is like a programming language, if everyone uses slightly
 different versions of a language, maintaining and porting code becomes
 difficult.

 And that's it. IDE's would only need one option more, Save As XML, which
 would send the .d code to the conversion tool which would then save it to
 disk as .xml. On loading a .xml file, they would send it to a standard XML
 transformation tool with the stylesheet the user wants and then the file
 would be loaded into memory in D format as always. Optionally the IDE

 allow for code style settings to be saved to a stylesheet using the
 stylesheet creation tool.
 The compiler would not change at all.

 Because you are never forced to use .xml files and because a standard .d

 .xml tool would be relatively easy to design for all platforms, and

 .xml to .d conversions can be done with just a stylesheet and standard

 that already exist for all platforms, XML wouldn't be a threat to using D

 multiple platforms at all. In the contrary!

 Sorry for the very long story, but I just *love* the idea!


 --
 Stijn
 OddesE_XYZ hotmail.com
 http://OddesE.cjb.net
 __________________________________________
 Remove _XYZ from my address when replying by mail

Jan 18 2002
next sibling parent reply "Pavel Minayev" <evilone omen.ru> writes:
"J. Daniel Smith" <j_daniel_smith deja.com> wrote in message
news:a2a3i3$2s14$1 digitaldaemon.com...

 1.  the D compiler already has support for "D in HTML", since it already
 deals with a .htm file, it can deal with a .xml file too

There is one major difference here. The way D handles HTML is pretty straightforward - it just throws away most tags, and only handles <code> specially. For XML, as you propose it, keywords are tags as well - so you got to have an XML parser embedded into the compiler. Why not make it an external, "filter" program?
 2.  Given that the compiler already has a mechanism for converting .htm

 to D, adding support for a .xml file using a built-in XSLT stylesheet is
 straightfoward.

Again it has to understand XSLT...
 3.  Most importantly, by the compiler supporting a particular "D in XML"
 dialect, we avoid a bunch of different and incompatiable styles of XML.

 course, with another XSLT tranform you can convert from one "D in XML"
 dialect to another).

Walter could just define one standard to be "official", without implementing it in the compiler. The language is in early stage of development, and if you write a clean syntax proposal AND an XML2D parser/translator for it, why not "apply" it?
Jan 18 2002
parent "J. Daniel Smith" <j_daniel_smith deja.com> writes:
And the way D would handle XML would be equally straight forward: take the
input XML stream, feed it through a XSLT stylesheet and send the resulting D
source code onto the rest of the compiler.  The "throwing away the tags"
operation would be done by the XSLT stylesheet.

The XML objects are already available on windows platforms; using them in
the D compiler just takes a little COM plumbing.  I'm NOT proposing that the
D compiler itself parse XML and implement an XSLT engine.

   Dan


"Pavel Minayev" <evilone omen.ru> wrote in message
news:a2a4kc$2sqc$1 digitaldaemon.com...
 "J. Daniel Smith" <j_daniel_smith deja.com> wrote in message
 news:a2a3i3$2s14$1 digitaldaemon.com...

 1.  the D compiler already has support for "D in HTML", since it already
 deals with a .htm file, it can deal with a .xml file too

There is one major difference here. The way D handles HTML is pretty straightforward - it just throws away most tags, and only handles <code> specially. For XML, as you propose it, keywords are tags as well - so you got to have an XML parser embedded into the compiler. Why not make it an external, "filter" program?
 2.  Given that the compiler already has a mechanism for converting .htm

 to D, adding support for a .xml file using a built-in XSLT stylesheet is
 straightfoward.

Again it has to understand XSLT...
 3.  Most importantly, by the compiler supporting a particular "D in XML"
 dialect, we avoid a bunch of different and incompatiable styles of XML.

 course, with another XSLT tranform you can convert from one "D in XML"
 dialect to another).

Walter could just define one standard to be "official", without

 it in the compiler. The language is in early stage of development, and if
 you write a clean syntax proposal AND an XML2D parser/translator for it,
 why not "apply" it?

Jan 21 2002
prev sibling next sibling parent reply "OddesE" <OddesE_XYZ hotmail.com> writes:
"J. Daniel Smith" <j_daniel_smith deja.com> wrote in message
news:a2a3i3$2s14$1 digitaldaemon.com...
 The only thing about this that I'd tweak is setting up the compiler to
 accept the XML file directly.

 1.  the D compiler already has support for "D in HTML", since it already
 deals with a .htm file, it can deal with a .xml file too

Correct, but it just takes the code between <CODE> and </CODE> tags and strips all other HTML tags in between...I would like to see a format that captures the structure of the code, not just adds some fancy formatting options to the plain text code.
 2.  Given that the compiler already has a mechanism for converting .htm

 to D, adding support for a .xml file using a built-in XSLT stylesheet is
 straightfoward.

Agreed. I hadn't thought of that. Just using a built-in XSLT stylesheet and the already existing standard conversion tools would be relatively easy.
 3.  Most importantly, by the compiler supporting a particular "D in XML"
 dialect, we avoid a bunch of different and incompatiable styles of XML.

 course, with another XSLT tranform you can convert from one "D in XML"
 dialect to another).

    Dan

Definitely this would be the ideal situation, but it requires extra work on the writer of the compiler. I think the most important thing is that a good, solid XML specification for converting D code to XML is made. I bet there are people on this newsgroup capable of doing that. DigitalMars would act like a standards committee, approving and embracing specification drafts, and then finally 'releasing' the final specification by publishing it on their Website. Any compiler would then be able to implement the specification if, when and how they see fit. -- Stijn OddesE_XYZ hotmail.com http://OddesE.cjb.net __________________________________________ Remove _XYZ from my address when replying by mail
Jan 18 2002
parent reply "Pavel Minayev" <evilone omen.ru> writes:
"OddesE" <OddesE_XYZ hotmail.com> wrote in message
news:a2a572$2t70$1 digitaldaemon.com...

 specification for converting D code to XML is made. I bet there are people
 on this newsgroup capable of doing that. DigitalMars would act like a
 standards
 committee, approving and embracing specification drafts, and then finally
 'releasing' the final specification by publishing it on their Website. Any
 compiler
 would then be able to implement the specification if, when and how they

 fit.

IMHO the best way to do that is to write an external filter in platform- independent D. Then, any implementation of D compiler, ported to any platform, can recompile that filter there, and author may rely on it later _without writing a piece of his own code to do that_. On other hand, if he wants, he can incorporate XML support into the compiler itself. Either way, since it costs him nothing to add this support, thus encouraging people to do so.
Jan 18 2002
parent reply "OddesE" <OddesE_XYZ hotmail.com> writes:
 IMHO the best way to do that is to write an external filter in platform-
 independent D.

Not persť. You see, you have to differentiate thinking about the conversion from D to XML, which is difficult because a tailor-made tool is needed, and the conversion from XML to D, which is relatively easy, because you only need a stylesheet (which is platform independent and only needs to be written once) and the standard conversion tools already available for almost every platform. Most of these conversion tools are available as API calls so the compiler could just load the stylesheet and make the necessary API calls. "Pavel Minayev" <evilone omen.ru> wrote in message news:a2a5j8$2thb$1 digitaldaemon.com...
 "OddesE" <OddesE_XYZ hotmail.com> wrote in message
 news:a2a572$2t70$1 digitaldaemon.com...

 specification for converting D code to XML is made. I bet there are


 on this newsgroup capable of doing that. DigitalMars would act like a
 standards
 committee, approving and embracing specification drafts, and then


 'releasing' the final specification by publishing it on their Website.


 compiler
 would then be able to implement the specification if, when and how they

 fit.

IMHO the best way to do that is to write an external filter in platform- independent D. Then, any implementation of D compiler, ported to any platform, can recompile that filter there, and author may rely on it later _without writing a piece of his own code to do that_. On other hand, if he wants, he can incorporate XML support into the compiler itself. Either way, since it costs him nothing to add this support, thus encouraging people to do so.

Jan 18 2002
parent reply "Pavel Minayev" <evilone omen.ru> writes:
"OddesE" <OddesE_XYZ hotmail.com> wrote in message
news:a2a7na$2ulr$1 digitaldaemon.com...

 tailor-made tool is needed, and the conversion from XML to
 D, which is relatively easy, because you only need a
 stylesheet (which is platform independent and only needs to
 be written once) and the standard conversion tools already
 available for almost every platform. Most of these conversion
 tools are available as API calls so the compiler could just load
 the stylesheet and make the necessary API calls.

APIs are usually not so easy as they tend to be. I wonder if there is a multi-platform console-mode XSLT converter (for any platform D could be ported to), though... it could be used for that purpose.
Jan 18 2002
parent reply "Pavel Minayev" <evilone omen.ru> writes:
"Pavel Minayev" <evilone omen.ru> wrote in message
news:a2a9vn$309e$1 digitaldaemon.com...

 APIs are usually not so easy as they tend to be.

Sorry, it's 2:30am, I haven't slept for 16 hours already and my brain occasionaly works improperly =) It should read: "...not so easy as they're thought to be."
Jan 18 2002
parent "OddesE" <OddesE_XYZ hotmail.com> writes:
"Pavel Minayev" <evilone omen.ru> wrote in message
news:a2aahd$30mq$1 digitaldaemon.com...
 "Pavel Minayev" <evilone omen.ru> wrote in message
 news:a2a9vn$309e$1 digitaldaemon.com...

 APIs are usually not so easy as they tend to be.

Sorry, it's 2:30am, I haven't slept for 16 hours already and my brain occasionaly works improperly =) It should read: "...not so easy as they're thought to be."

:) I got it the first time ;)
Jan 18 2002
prev sibling parent "J. Daniel Smith" <j_daniel_smith deja.com> writes:
Here's a slightly different twist on this topic that I don't think has been
explicitly stated yet:

The idea of DML is nothing more than a generalization of of "D in HTML".  To
wit: HTML (or more precisely XHTML) is a XML dialect.  Given that, a XSLT
transform can be used to "strip" the HTML tags from the .htm input file
leaving you with raw D source code; in other words the same thing the D
compiler current does with specialized code can be done in a general manner
using a XSLT tranform.

So now that we have a general mechanism of getting from a XML input file
(XHTML) into D source code, the next step is to come up with a way of
expressing D constructs in XML which results in DML.  The only thing that's
really any different from the existing "HTML to D" process is that some tags
(such as '<d:for>') are altered (transformed) instead of merely being
stripped.

   Dan

"J. Daniel Smith" <j_daniel_smith deja.com> wrote in message
news:a2a3i3$2s14$1 digitaldaemon.com...
 The only thing about this that I'd tweak is setting up the compiler to
 accept the XML file directly.

 1.  the D compiler already has support for "D in HTML", since it already
 deals with a .htm file, it can deal with a .xml file too
 2.  Given that the compiler already has a mechanism for converting .htm

 to D, adding support for a .xml file using a built-in XSLT stylesheet is
 straightfoward.
 3.  Most importantly, by the compiler supporting a particular "D in XML"
 dialect, we avoid a bunch of different and incompatiable styles of XML.

 course, with another XSLT tranform you can convert from one "D in XML"
 dialect to another).

    Dan

 "OddesE" <OddesE_XYZ hotmail.com> wrote in message
 news:a29u9b$2ola$1 digitaldaemon.com...
 "Pavel Minayev" <evilone omen.ru> wrote in message
 news:a28v11$1pj1$1 digitaldaemon.com...
 This is all great, but I tell you one thing. I'm never going
 to type in program in XML, and I don't want to use a converter
 each time I'm going to compile it as well. Yes, IDEs, all is
 great - but on *NIX many people still use vi to edit files and
 command-line to compile them - and they won't be happy of any
 additional step that is to be introduced. XML could be _one_
 of possible input formats for D, but definitely not the primary.

 Also, one idea about all this. What if D compiler supports some
 sort of "filters" - it feeds them the source code from the
 file and then compiles their output. This way, an XML filter
 could be easily written, as well as many others exotic formats;
 HTML could be done as a filter as well...

Oh I definitely agree! I didn't mean to say you should *write* the code in XML! That would be undoable! :) XML is not really meant to be read, let alone written, by humans. It is a data representation format designed for computers. This is what I imagine: You type in your function in the editor, just like you would always do, using your own coding style, like this: void Func(int iCount) { for (int i=0; i<iCount; i++) { printf ("Hello world.\n"); } } To you there is absolutely *no* difference. The editor stores the file in memory in normal .d format until it is

 at which time it saves it in .d or .xml format, whichever you prefer.

 assume for the moment you choose .xml, although there isn't a single

 why saving in .d would be impossible or even difficult.
 When you run your program, the IDE sends plain .d code (no XML) to the
 compiler, which compiles it, after which it can be linked and run. No
 changes there either, the compiler stays exactly the same, no need for


 special filters or anything.
 After you finish your work and close the IDE, the files are saved on


 harddisk in .xml format. The next day you open the .xml files again and

 your function like this:

 void Func(int iCount) {
     for (int i=0; i<iCount; i++) {
         printf ("Hello world.\n");
     }
 }

 exactly the same!
 But now I come in. You decide you need another programmer for, say,
 maintenance coding, and you hire me for the job. I however, have my own
 coding style, and set my IDE to different settings, so when I load your

 file containing the Func function, I see this:

 void Func (int iCount)
 {
     for (int i=0; i<iCount; i++)
     {
         printf ("Hello world.\n");
     }
 }

 And, when it comes to the official documentation, written in say HTML,


 would only need one .XSL stylesheet that defines the conversion, to

 .html files that all use exactly the same coding style and syntax


 options. Better still, because the .xml files contain no information


 style, just the pure code, changing the company style for all thousand
 programmers would be as easy as changing one XSL stylesheet and


 the documentation files from the original .xml source code files. Every
 programmer in the organisation could use his own personal style, without
 having to compromise to the style of any other programmer, and the .xml
 files wouldn't change one bit!

 If you now think to yourself, this is too good to be true, and you have

 kinds of objections for why this can't be possible or would be very
 impractical, let me try to address some of the first ones that came into

 mind:

 - XML files are unreadble for humans:

 As described above, this should not be a problem, you should never have


 read or write a single letter of XML. You code in D, like you always


 - XML files are too complex:

 Although .xml files indeed do look very complex to humans, to computers

 are actually very easily parsable, they were intentionally designed that
 way.

 - I would have to choose between .xml and .d file formats:

 XML was designed with format conversions in mind. The conversion from .d

 XML is specific to the D language, so you would need a tool, filter,

 component or whatever to do that, but conversion from XML to any other
 format, including HTML, PDF, DOC or just back to D again would only

 writing a XSL stylesheet. There are standard XML parsers and conversion
 tools that can then do the conversion job. This means you could use


 as .d for years, then one day convert all these .d files to .xml in one
 large swoop and immediately gain all the benefits of .xml. It also works

 other way around. You could save as .xml for years and then one day

 them all back to .d again. At no point in time would you ever be forced


 choose between saving as .d or as .xml without a very simple way to

 that choice.

 - I would need to write complex stylesheets:

 Most probably not. You *could* write your own stylesheet, but you


 would leave such  tasks to the IDE or 3rd-party specialised tools.

 - To include the option of saving as XML would require an enormeous


 of work, special compilers and IDE's, and would overall be a threat to

 D on different platforms:

 Definitely not.
 To include the option to save as .xml you would need:
 1) A solid XML specification for translating D code to XML.
 2) A tool to convert D code to XML according to that specification.
 3) A tool to create custom stylesheets based on settings such as

 type,
 tabs/versus spaces etc.

 1) and 2) are vital, but the stylesheets could be written by hand in the
 beginning, and a few common ones with standard code style features could

 placed on a website.
 Also, only the XML specification is time critical, because you could use


 without XML just fine for as long as it would take for the D to XML
 conversion tools to be designed. Ofcourse the XML specification needs to

 well defined before you can start building the conversion tool(s).
 Designing a solid XML specification for translating D code to XML


 be easy, but it would be peanuts compared to designing a whole language

 largely follows from the syntax and structure rules for D. It does need


 be an 'official' specification, because if there would be many


 different versions you would soon lose a lot of the big benefits of


 In
 that respect it is like a programming language, if everyone uses


 different versions of a language, maintaining and porting code becomes
 difficult.

 And that's it. IDE's would only need one option more, Save As XML, which
 would send the .d code to the conversion tool which would then save it


 disk as .xml. On loading a .xml file, they would send it to a standard


 transformation tool with the stylesheet the user wants and then the file
 would be loaded into memory in D format as always. Optionally the IDE

 allow for code style settings to be saved to a stylesheet using the
 stylesheet creation tool.
 The compiler would not change at all.

 Because you are never forced to use .xml files and because a standard .d

 .xml tool would be relatively easy to design for all platforms, and

 .xml to .d conversions can be done with just a stylesheet and standard

 that already exist for all platforms, XML wouldn't be a threat to using


 on
 multiple platforms at all. In the contrary!

 Sorry for the very long story, but I just *love* the idea!


 --
 Stijn
 OddesE_XYZ hotmail.com
 http://OddesE.cjb.net
 __________________________________________
 Remove _XYZ from my address when replying by mail


Jan 23 2002
prev sibling parent reply "Juan Carlos Arevalo Baeza" <jcab roningames.com> writes:
"OddesE" <OddesE_XYZ hotmail.com> wrote in message
news:a27qo9$11p3$1 digitaldaemon.com...

 Friends I have always write codeblocks like this:

 void Func(int iCount) {
     for (int i=0; i<iCount; i++) {
         printf ("Hello world.\n");
     }
 }

 Now imagine that beneath the surface the IDE would save the code above in
 XML like this:

 <?xml version="1.0">
 <Program>
     <Module name="main">
         <Function name="Func">
             <Return>void</Return>
             <Argument name="iCount">int</Argument>
             <CodeBlock>
                 <For>
                     <ForInitializer>int i=0</ForInitializer>
                     <ForUpdater>i<iCount</ForUpdater>
                     <ForEvaluation>i<iCount</ForEvaluation>
                     <CodeBlock>
                         printf ("Hello world.\n");
                     </CodeBlock>
                 </For>
             </CodeBlock>
         </Function>
     </Module>
 </Program>

 It looks very complex, but it contains the same information as the .d

 Now it would be a breeze to change all kinds of layout settings to create
 another .d file with exactly the same source code, but with a different
 view on that source code.

You're forgetting something really important: comments. They are out-of-code, human-readable annotations, and they must be preserved together with the part of the program that they reference. Now, consider this three possible layouts (all of which I've seen used): --- class A { void Func1(); // Function 1 void Func2(); // Function 2 } --- --- class A { // Function 1 void Func1(); // Function 2 void Func2(); } --- --- class A { void Func1(); // Function 1 void Func2(); // Function 2 } --- It would be impossible to parse this into a XML structure like the one above without losing something in the process or, even worse, putting things where they don't belong. In order for this to work, comments must be done in some different way that I can't quite imagine right now. Maybe like Doxygen (and such tools do), adding markers so you give indications to a "comment parser". Salutaciones, JCAB
Jan 18 2002
next sibling parent reply "OddesE" <OddesE_XYZ hotmail.com> writes:
"Juan Carlos Arevalo Baeza" <jcab roningames.com> wrote in message
news:a2adt9$1ff$1 digitaldaemon.com...
<SNIP>
    You're forgetting something really important: comments. They are
 out-of-code, human-readable annotations, and they must be preserved

 with the part of the program that they reference. Now, consider this three
 possible layouts (all of which I've seen used):

 ---
 class A {
    void Func1(); // Function 1
    void Func2(); // Function 2
 }
 ---

 ---
 class A {
    // Function 1
    void Func1();
    // Function 2
    void Func2();
 }
 ---

 ---
 class A {
    void Func1();
       // Function 1
    void Func2();
       // Function 2
 }
 ---

    It would be impossible to parse this into a XML structure like the one
 above without losing something in the process or, even worse, putting

 where they don't belong.

    In order for this to work, comments must be done in some different way
 that I can't quite imagine right now. Maybe like Doxygen (and such tools
 do), adding markers so you give indications to a "comment parser".

 Salutaciones,
                          JCAB

Putting things where they "don't belong"might be actually exactly what I want, because I generally don't agree with the coding styles others use. But you could always make comments store some additional info, such as row, column values, to include that extra precision. You do make a very vald point however and it is definitely something to keep in mind. -- Stijn OddesE_XYZ hotmail.com http://OddesE.cjb.net __________________________________________ Remove _XYZ from my address when replying by mail
Jan 18 2002
parent "Juan Carlos Arevalo Baeza" <jcab roningames.com> writes:
"OddesE" <OddesE_XYZ hotmail.com> wrote in message
news:a2av77$cav$1 digitaldaemon.com...

 ---
 class A {
    void Func1(); // Function 1
    void Func2(); // Function 2
 }
 ---

    It would be impossible to parse this into a XML structure like the


 above without losing something in the process or, even worse, putting

 where they don't belong.

Putting things where they "don't belong"might be actually exactly what I want, because I generally don't agree with the coding styles others use.

:) By "putting things where they don't belong", I mean the parser, not you :) In the case above, a parser can easily apply the comment "Function 1" to Func2(), which is wrong. Doxygen, for example, requires you to add characters at the beginning of in-line comments as follows: --- class A { void Func1(); ///< Function 1 void Func2(); ///< Function 2 } --- Salutaciones, JCAB
Jan 21 2002
prev sibling parent "J. Daniel Smith" <j_daniel_smith deja.com> writes:
Comments are part of the "HTML" documentation that started this whole
thread.

Since everything is now XML, commentary (written in XHTML) can be pretty
much freely mixed in with the XML-D source code.  The XSLT stylesheet would
determine how everything is rendered; the XSLT stylesheet that the D
compiler uses for example would just ignore all of the XHTML stuff since it
doesn't care about comments.

I would reserve real XML comments ('<!-- comment -->') for the tools
themselves - maybe things like line numbers or the like.

   Dan

"Juan Carlos Arevalo Baeza" <jcab roningames.com> wrote in message
news:a2adt9$1ff$1 digitaldaemon.com...
 "OddesE" <OddesE_XYZ hotmail.com> wrote in message
 news:a27qo9$11p3$1 digitaldaemon.com...

 Friends I have always write codeblocks like this:

 void Func(int iCount) {
     for (int i=0; i<iCount; i++) {
         printf ("Hello world.\n");
     }
 }

 Now imagine that beneath the surface the IDE would save the code above


 XML like this:

 <?xml version="1.0">
 <Program>
     <Module name="main">
         <Function name="Func">
             <Return>void</Return>
             <Argument name="iCount">int</Argument>
             <CodeBlock>
                 <For>
                     <ForInitializer>int i=0</ForInitializer>
                     <ForUpdater>i<iCount</ForUpdater>
                     <ForEvaluation>i<iCount</ForEvaluation>
                     <CodeBlock>
                         printf ("Hello world.\n");
                     </CodeBlock>
                 </For>
             </CodeBlock>
         </Function>
     </Module>
 </Program>

 It looks very complex, but it contains the same information as the .d

 Now it would be a breeze to change all kinds of layout settings to


 another .d file with exactly the same source code, but with a different
 view on that source code.

You're forgetting something really important: comments. They are out-of-code, human-readable annotations, and they must be preserved

 with the part of the program that they reference. Now, consider this three
 possible layouts (all of which I've seen used):

 ---
 class A {
    void Func1(); // Function 1
    void Func2(); // Function 2
 }
 ---

 ---
 class A {
    // Function 1
    void Func1();
    // Function 2
    void Func2();
 }
 ---

 ---
 class A {
    void Func1();
       // Function 1
    void Func2();
       // Function 2
 }
 ---

    It would be impossible to parse this into a XML structure like the one
 above without losing something in the process or, even worse, putting

 where they don't belong.

    In order for this to work, comments must be done in some different way
 that I can't quite imagine right now. Maybe like Doxygen (and such tools
 do), adding markers so you give indications to a "comment parser".

 Salutaciones,
                          JCAB

Jan 21 2002