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


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 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


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
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


file

 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.


(Of

 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


 file

 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.


 (Of

 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 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


file

 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.


(Of

 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


see

 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




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.


 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


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


 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 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


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.


   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


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



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




one

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


 things

 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




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.


    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 21 2002