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

"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  ;)

"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

"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

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

"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

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

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