"OddesE" <OddesE_XYZ@hotmail.com> wrote in message news:a271jv$h2p$1@digitaldaemon.com...

> The average piece of source code is (re)written a few times, compiled a
few
> dozen times and read a few hundred times. The point is that reading source code is important and happens a lot. So source is not just supposed to be compiled.

Definitely. But syntax-highlighted source code, together with class
browser -
all nifty things that modern IDEs do have - are pretty much enough, IMO.


> I think it would be great to choose Save As XML in the IDE, then be able
to
> generate from this XML file:
> - An original .d file back again
> - A standard .html file which uses only plain HTML, no javascript, css,
> dhtml, etc. and could therefore be understood by even the oldest browsers.
> - Complexer .html files which do use the above options
> - .pdf, .rtf, .doc word processing documents, for easy printing of the
> source code
> - Anything you can imagine!

Nothing against this. But why make the _compiler_ support that XML output as one of possible source code formats? Convertor would work just fine.

1. The compiler is already supporting the HTML format
2. With the right XML schema to start with, it's would be straight-forward
to turn XML into D source code
3. Always having to externally preprocess a file before sending it to the
compiler is can be a major nusiance

   Dan

"Pavel Minayev" <evilone@omen.ru> wrote in message news:a2729l$hk2$1@digitaldaemon.com...
> "OddesE" <OddesE_XYZ@hotmail.com> wrote in message news:a271jv$h2p$1@digitaldaemon.com...
>
> > The average piece of source code is (re)written a few times, compiled a
> few
> > dozen times and read a few hundred times. The point is that reading
source
> > code is important and happens a lot. So source is not just supposed to
be
> > compiled.
>
> Definitely. But syntax-highlighted source code, together with class
> browser -
> all nifty things that modern IDEs do have - are pretty much enough, IMO.
>
>
> > I think it would be great to choose Save As XML in the IDE, then be able
> to
> > generate from this XML file:
> > - An original .d file back again
> > - A standard .html file which uses only plain HTML, no javascript, css,
> > dhtml, etc. and could therefore be understood by even the oldest
browsers.
> > - Complexer .html files which do use the above options
> > - .pdf, .rtf, .doc word processing documents, for easy printing of the
> > source code
> > - Anything you can imagine!
>
> Nothing against this. But why make the _compiler_ support that XML output as one of possible source code formats? Convertor would work just fine.
>
>
>
>

You wouldn't actually look at the XML based D source code in normal development.  When you load the XML file into the IDE, your personal source-code formatting options (color, indentation, etc.) are applied (a XSLT transform) to present "normal" D source code to you.

Coding your example in XML, we might have something like
    <d:function name="MyFunction" type="void">
        <d:call name="printf">
            <d:param value="Hello World!\n" />
        </d:call>
    </d:function>
when I load this XML file using my preferences I would see
   void MyFunction() {
      printf("Hello World.\n");
   }
while when you loaded the SAME file, you would see
   void MyFunction()
   {
     printf ("Hello World.\n");
   }
the source code (the XML file) is NOT changed.  The D compiler doesn't care
about whitespace anyway, so it uses a different XSLT tranform to generate
'void MyFunction(){printf("Hello World.\n");}'.

   Dan

"OddesE" <OddesE_XYZ@hotmail.com> wrote in message news:a271jv$h2p$1@digitaldaemon.com...
> "Pavel Minayev" <evilone@omen.ru> wrote in message news:a21rf9$5vr$1@digitaldaemon.com...
> > "J. Daniel Smith" <j_daniel_smith@deja.com> wrote in message news:a21kf4$qn$1@digitaldaemon.com...
> >
> > > I would contend that as soon as you use D source file for something
> other
> > > than generating an OBJ file, you're treating the source not as code,
but
> > as
> > > data.
> >
> > What else could you it for? Programs are supposed to be compiled, at
least
> > I always thought so... =)
> >
>
> The average piece of source code is (re)written a few times, compiled a
few
> dozen times and read a few hundred times. The point is that reading source code is important and happens a lot. So source is not just supposed to be compiled.
>
> I think it would be great to choose Save As XML in the IDE, then be able
to
> generate from this XML file:
> - An original .d file back again
> - A standard .html file which uses only plain HTML, no javascript, css,
> dhtml, etc. and could therefore be understood by even the oldest browsers.
> - Complexer .html files which do use the above options
> - .pdf, .rtf, .doc word processing documents, for easy printing of the
> source code
> - Anything you can imagine!
>
> Saving a piece of source code in .xml in a well thought out format, could add a LOT to what you can do with it. Think of this piece of code:
>
> void MyFunction() {
>     printf ("Hello World.\n");
> }
>
> Great, but I personally prefer this style:
>
> void MyFunction()
> {
>     printf ("Hello World.\n");
> }
>
> with the opening brace on a separate line.
> Saving in .xml would mean you could easily convert the .xml document back
to .d, but with the layout parameters you have chosen, such as number of spaces / tabs to indent, open-braces on a new line or not et. etc.
>
>
> > > With D2HTML, you have another program that does some (trival) parsing
of a
> > D
> > > source file to generate HTML.  Not a big deal, but now you want to
> > generate
> > > a call graph: another program and another bunch of parsing.  Using XML
>  and
> > > XSLT you get a lot of this "for free", no need to write a program to
> parse
> > a
> > > D source file.
> >
> > Yes, but you have to get that XML first, noone is going to write
programs
> > in XML for you - so another parser and another generator... it'd
probably
> > be better to write a D parser in D that generates the syntax tree in memory, without any additional steps.
> >
> > > XML is intended to be a general-purpose means of encoding data -
you've
> > > pretty much done the same thing with the <span> tags since you have a different "class" attribute for keywords, numbers, etc.  That's
exactly
> > the
> > > type of thing I have in mind, other than I think that a more rigorous
> XML
> > > schema is needed.
> >
> > <span> will be correctly rendered even in IE4 and NS4. XML requires a modern browser - something that is not always accessible on *NIX boxes. And <font> is understood even by text browsers! So for syntax highlighting at least, I believe XML is not the best idea.
>
> It is *very* easy to convert a well-formed .xml document to plain .html
that
> every browser can understand.
>
> I think it is generally a very good idea to use .xml as a intermediate document format. Also it isn't that hard, you only have to write a good specification, than all compilers could choose wheter to implement a Sava
as
> XML option or not. In the meantime third-party tools could be written to convert .d files to .xml. The tools to convert .xml to .pdf, .html etc.
etc.
> already exist!
>
>
> *Die hard D fan!!*
>
> --
> Stijn
> OddesE_XYZ@hotmail.com
> http://www.OddesE.f2s.com
> __________________________________________
> Remove _XYZ from my address when replying by mail
>
>
>

"Pavel Minayev" <evilone@omen.ru> wrote in message news:a2729l$hk2$1@digitaldaemon.com...
> Nothing against this. But why make the _compiler_ support that XML output as one of possible source code formats? Convertor would work just fine.


One side effect of D being easy to parse, is so that specialized tools such as an XML converter can be easilly made!

And then your error message line numbers come out all wrong.  ;)

What should happen is that the IDE should take D as input, parse it, convert internally to some graph/tree format, convert to .html for pretty printed viewing in the editor, take changes made and reparse those sections into the internal format, and when you hit Compile or Save it converts the tree back into .D source.  (or the compiler could just accept the preparsed tree directly... nobody ever said the parsing and compiling and code generation all had to happen together in time, or by the same program even)

Thing is, it's up to the IDE to provide all this nifty functionality, but you don't want the D language specification to *mandate* it.

Sean

"J. Daniel Smith" <j_daniel_smith@deja.com> wrote in message news:a27ill$snl$1@digitaldaemon.com...
> You wouldn't actually look at the XML based D source code in normal development.  When you load the XML file into the IDE, your personal source-code formatting options (color, indentation, etc.) are applied (a XSLT transform) to present "normal" D source code to you.
>
> Coding your example in XML, we might have something like
>     <d:function name="MyFunction" type="void">
>         <d:call name="printf">
>             <d:param value="Hello World!\n" />
>         </d:call>
>     </d:function>
> when I load this XML file using my preferences I would see
>    void MyFunction() {
>       printf("Hello World.\n");
>    }
> while when you loaded the SAME file, you would see
>    void MyFunction()
>    {
>      printf ("Hello World.\n");
>    }
> the source code (the XML file) is NOT changed.  The D compiler doesn't
care
> about whitespace anyway, so it uses a different XSLT tranform to generate
> 'void MyFunction(){printf("Hello World.\n");}'.
>
>    Dan

"Sean L. Palmer" <spalmer@iname.com> wrote in message news:a28j3m$1gj3$1@digitaldaemon.com...
> And then your error message line numbers come out all wrong.  ;)

No, because you look at exactly the same code (the .d code that was the
result of converting the .xml file to .d) that is sent to the compiler.
Neither
you, nor the compiler ever sees the .xml file, it is just used for saving in
an independant format.

>
> What should happen is that the IDE should take D as input, parse it,
convert
> internally to some graph/tree format, convert to .html for pretty printed viewing in the editor, take changes made and reparse those sections into
the
> internal format, and when you hit Compile or Save it converts the tree
back
> into .D source.  (or the compiler could just accept the preparsed tree directly... nobody ever said the parsing and compiling and code generation all had to happen together in time, or by the same program even)
>


Correct, but it probably wouldn't want to save that graph/tree in
a file. Saving from the internal representation into XML is a simple,
portable and powerful solution for that, and generating all kinds of
other documents, not just HTML, from a source .xml file is relatively
easy and requires no extra code, just a XSLT stylesheet.


> Thing is, it's up to the IDE to provide all this nifty functionality, but you don't want the D language specification to *mandate* it.
>
> Sean

I definitely agree. DigitalMars should only provide an XML
specification for converting D code to XML. Anyone would
then be totally free in if and how they would implement saving
as .xml.


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

"OddesE" <OddesE_XYZ@hotmail.com> wrote in message news:a2a47j$2sdp$1@digitaldaemon.com...

> I definitely agree. DigitalMars should only provide an XML
> specification for converting D code to XML. Anyone would
> then be totally free in if and how they would implement saving
> as .xml.

Seems like it's time to establish an... mmmm... "D XML commitee", Walter! =) And then you can just approve whatever they come with...

OddesE wrote:

> "Sean L. Palmer" <spalmer@iname.com> wrote in message
> news:a28j3m$1gj3$1@digitaldaemon.com...
> 
>>And then your error message line numbers come out all wrong.  ;)
>>
> 
> No, because you look at exactly the same code (the .d code that was the
> result of converting the .xml file to .d) that is sent to the compiler.
> Neither
> you, nor the compiler ever sees the .xml file, it is just used for saving in
> an independant format.



The .XML-to-D-for-purposes-of-compiler-input translation needs
to provide to the compiler a way for the compiler's error reports
to correspond to the line layout that you use in your editor.
As you noted, your particular settings will change the line
layout. Here you need a lot of cooperation between the editor and
the compiler and the XML/D translator to tell you where your
compilation errors are. It's not impossible, but given that D
is currently a one-man effort (though Pavel is certainly starting
to make it look like a two-man effort), it's not going to happen
this year.

-Russell B

"Russell Borogove" <kaleja@estarcion.com> wrote in message news:3C48B248.7070206@estarcion.com...

> The .XML-to-D-for-purposes-of-compiler-input translation needs to provide to the compiler a way for the compiler's error reports to correspond to the line layout that you use in your editor.

You don't edit XML code in the editor - you edit D code! And you compile that code. But if you want to give your program to somebody, you can (but don't have to!) save it as XML. Then he loads it, converting back to D; of course he gets line numbers different from yours, but the code fed to his compiler is once again what _he_ sees on the screen.

> is currently a one-man effort (though Pavel is certainly starting to make it look like a two-man effort), it's not going to happen

Me??? =)

Pavel Minayev wrote:

> "Russell Borogove" <kaleja@estarcion.com> wrote in message
> news:3C48B248.7070206@estarcion.com...
> 
> 
>>The .XML-to-D-for-purposes-of-compiler-input translation needs
>>to provide to the compiler a way for the compiler's error reports
>>to correspond to the line layout that you use in your editor.
>>
> 
> You don't edit XML code in the editor - you edit D code!


This point I understand.

> And you compile that code.


Ah, okay, I was envisioning a world where the XML version
of the source was the source code of record, and would be
submitted to the compiler via a separate XML-to-D translation
process (which might use different bracing options than
the programmer's preference). In a more elaborate source-code-
in-database system, this could get more problematic.


>>is currently a one-man effort (though Pavel is certainly starting
>>to make it look like a two-man effort), it's not going to happen
>>
> 
> Me??? =)


You've done a fair amount of work getting legacy libraries
usable in D, and you've reported far more bugs than anyone
else. I haven't even invoked the damn compiler yet, shameful
to admit.

-RB