www.digitalmars.com         C & C++   DMDScript  

c++.announce - Dr. Dobb's and the D Programming Language

reply "Walter" <walter digitalmars.com> writes:
D made the cover of February Dr. Dobbs!

www.ddj.com
Jan 05 2002
next sibling parent reply Roland <rv ronetech.com> writes:
Walter a écrit :

 D made the cover of February Dr. Dobbs!

 www.ddj.com

Aoouuo ! Roland
Jan 07 2002
parent reply "Robert W. Cunningham" <rcunning acm.org> writes:
Roland wrote:

 Walter a écrit :

 D made the cover of February Dr. Dobbs!

 www.ddj.com

Aoouuo ! Roland

A concise, well-written article. Congrats! I only wish it were twice as long, and mentioned the existence of the alpha version compiler! -BobC
Jan 08 2002
parent roland <nancyetroland free.fr> writes:
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

"Robert W. Cunningham" a écrit :

 Roland wrote:

 Walter a écrit :

 D made the cover of February Dr. Dobbs!

 www.ddj.com

Aoouuo ! Roland

A concise, well-written article. Congrats! I only wish it were twice as long, and mentioned the existence of the alpha version compiler! -BobC

Lets try again in a few days.. Roland
Jan 14 2002
prev sibling parent reply Alex Vincent <jscript pacbell.net> writes:
Walter wrote:
 D made the cover of February Dr. Dobbs!
 
 www.ddj.com

How do you think I found out about it? 8-) Greetings, everyone. I must say the concepts D brings about are really quite interesting. I come from a background of web design, and my own book, the JavaScript Developer's Dictionary, should be on shelves in a couple months. I'm fairly active in the Mozilla.org project as well, and I tinker around and study the WWW all the time. So maybe I can bring an outsider's perspective to all this. First off, let me point out one particular misconception on the D web site. The <code>...</code> tag, like many HTML elements, provides little more than stylistic appearance. It is NOT meant to contain live code, only examples thereof. The more appropriate element would be <object>...</object>. If you intend the code to be interpreted, perhaps a <script type="application/x-d">...</script> element would be appropriate. XML can handle scripting easily: we simply use an <html:script>...</html:script> element. The "html" part is an XML namespace. I do not know how they relate to D or C++ namespaces. But we typically define an XML namespace by using the prefix as a local name for an "xmlns" namespace: <root xmlns="http://digitalmars/xml-namespaces/root" xmlns:html="http://www.w3.org/1999/xhtml" > <html:script type="text/javascript"> alert("Hello World") </html:script> </root> Similarly, you could use <html:object><html:param /></html:object> elements if you decided not to go the scripting route. XML also allows the use of processing instructions <?target data ?>, where target identifies the program supposed to execute the code. PHP, for instance, uses <?php ?> (when you have the short form disabled). The data, for PHP anyway, indicates the code to execute. Now, for a change of subject. ECMAScript, popularly known by its Netscape-trademarked name JavaScript, and the W3C Document Object Model, are two of my favorite subjects. (I wrote a whole book on them, and I still learn new facts quite often.) I of course like the idea of mixing programming / scripting and markup languages together. I alluded to using D as a scripting language for (X)HTML pages earlier. I wonder if anyone has a working example of this I could see. I'll tell you, from a JavaScript developer's perspective, the concept of contracts just blew me away. I'm very very impressed by that, and it's one thing I already wish JavaScript could support easily. Alas... Personally, I'd go absolutely bonkers if someone could write an ECMAScript-compatible engine, like Mozilla.org's JavaScript1.5 beta engine. I don't know if you guys have been able to write a D compiler in D yet (I understand break-even is a very significant milestone), but if C++ can handle interpretation of another language... Of course, this whole paragraph is pipe dream stuff for a language whose compiler is in the alpha stage. Likewise, I'd love to see a DOM implemetation as well one day. That would require translating from the W3C DOM, particularly the IDL. Even if it's just determining the object tree, it'd be beautiful. Am I insane to mention these things here, now? Probably. Do I understand what you guys talk about? Somewhat. Would I be able to help you in the development of the D language? Only if it was in QA, most likely. Am I interested in this project? You betcha. I've got my hands in a couple dozen other projects, but I do want to follow this one, at least peripherally. I'll watch this thread for a few days, see what you guys think, and I'll keep in touch. I hope I haven't insulted your intelligences with the above comments. Bottom line is I like what I see, and I'd love to support you guys in building this language. (No, not with money. I don't have any.) Alex Vincent Vallejo, CA
Jan 10 2002
next sibling parent "Pavel Minayev" <evilone omen.ru> writes:
"Alex Vincent" <jscript pacbell.net> wrote in message
news:3C3E994B.7020806 pacbell.net...

 First off,  let me point out one particular misconception on the D web
 site.  The <code>...</code> tag, like many HTML elements, provides
 little more than stylistic appearance.  It is NOT meant to contain live
 code, only examples thereof.  The more appropriate element would be
 <object>...</object>.  If you intend the code to be interpreted, perhaps
 a <script type="application/x-d">...</script> element would be

It's not intended to be interpreted - D is not a scripting language for Web. I believe it was introduced to allow writing of commented, syntax-colored samples, probably even with embedded diagrams and screenies, but still compileable. Usually you get two files - one .html and one with the source. Now, you get one .html which you can compile.
 Personally, I'd go absolutely bonkers if someone could write an
 ECMAScript-compatible engine, like Mozilla.org's JavaScript1.5 beta
 engine.  I don't know if you guys have been able to write a D compiler
 in D yet (I understand break-even is a very significant milestone), but
 if C++ can handle interpretation of another language...  Of course, this
 whole paragraph is pipe dream stuff for a language whose compiler is in
 the alpha stage.

This is an interesting idea. Some other D features (like slicing) could also be used in ECMAScript-compatible language (DScript?). Definitely, this is not something to happen in near future...
 Am I insane to mention these things here, now?  Probably.  Do I
 understand what you guys talk about?  Somewhat.  Would I be able to help
 you in the development of the D language?  Only if it was in QA, most
 likely.

You can share your ideas. Contribute code, sample programs. Translate APIs =)...
Jan 11 2002
prev sibling next sibling parent reply "J. Daniel Smith" <j_daniel_smith deja.com> writes:
I too heard about D through the Dr. Dobbs article and was interested enough
to checkout the website.

The embeded HTML stuff reminded me of a random thought I had a while ago:
rather than just put D source code inside of <code> and use HTML constructs
like <font> and <br> for "pretty printing", why not make the whole thing
XML?  I haven't thought about this in near enough detail (remember, a
"random thought") to say how it would work for everything, but the basic
idea is that instead of writing HTML code like
    <code>
    void hello(int times)
    {
        int i;
        for (i = 0; i<times; i++)
        {
            printf("Hello World!\n");
        }
    }
    </code>
you would instead write XML something like
    <d:function name="hello" type="void">
        <d:arg name="times" type="int" />
        <d:var name="i" type="int" />
        <dkwd:for init="i=0" test="i<times"; incr="i++">
            <d:call name="printf">
                <d:param value="Hello World!\n" type="string" />
            </d:call>
        </dkwd:for>
    </d:function>
With everything in XML you can use two different XSLT transforms: one to
generate D code to feed to the compiler, and another to generate HTML for
documentation.

   Dan

"Alex Vincent" <jscript pacbell.net> wrote in message
news:3C3E994B.7020806 pacbell.net...
 Walter wrote:
 D made the cover of February Dr. Dobbs!

 www.ddj.com

How do you think I found out about it? 8-) Greetings, everyone. I must say the concepts D brings about are really quite interesting. I come from a background of web design, and my own book, the JavaScript Developer's Dictionary, should be on shelves in a couple months. I'm fairly active in the Mozilla.org project as well, and I tinker around and study the WWW all the time. So maybe I can bring an outsider's perspective to all this. First off, let me point out one particular misconception on the D web site. The <code>...</code> tag, like many HTML elements, provides little more than stylistic appearance. It is NOT meant to contain live code, only examples thereof. The more appropriate element would be <object>...</object>. If you intend the code to be interpreted, perhaps a <script type="application/x-d">...</script> element would be

 XML can handle scripting easily:  we simply use an
 <html:script>...</html:script> element.  The "html" part is an XML
 namespace.  I do not know how they relate to D or C++ namespaces.  But
 we typically define an XML namespace by using the prefix as a local name
 for an "xmlns" namespace:

 <root xmlns="http://digitalmars/xml-namespaces/root"
        xmlns:html="http://www.w3.org/1999/xhtml"
        >
 <html:script type="text/javascript">
 alert("Hello World")
 </html:script>
 </root>

 Similarly, you could use <html:object><html:param /></html:object>
 elements if you decided not to go the scripting route.

 XML also allows the use of processing instructions <?target data ?>,
 where target identifies the program supposed to execute the code.  PHP,
 for instance, uses <?php ?> (when you have the short form disabled).
 The data, for PHP anyway, indicates the code to execute.

 Now, for a change of subject.  ECMAScript, popularly known by its
 Netscape-trademarked name JavaScript, and the W3C Document Object Model,
 are two of my favorite subjects.  (I wrote a whole book on them, and I
 still learn new facts quite often.)  I of course like the idea of mixing
 programming / scripting and markup languages together.

 I alluded to using D as a scripting language for (X)HTML pages earlier.
   I wonder if anyone has a working example of this I could see.  I'll
 tell you, from a JavaScript developer's perspective, the concept of
 contracts just blew me away.  I'm very very impressed by that, and it's
 one thing I already wish JavaScript could support easily.  Alas...

 Personally, I'd go absolutely bonkers if someone could write an
 ECMAScript-compatible engine, like Mozilla.org's JavaScript1.5 beta
 engine.  I don't know if you guys have been able to write a D compiler
 in D yet (I understand break-even is a very significant milestone), but
 if C++ can handle interpretation of another language...  Of course, this
 whole paragraph is pipe dream stuff for a language whose compiler is in
 the alpha stage.

 Likewise, I'd love to see a DOM implemetation as well one day.  That
 would require translating from the W3C DOM, particularly the IDL. Even
 if it's just determining the object tree, it'd be beautiful.

 Am I insane to mention these things here, now?  Probably.  Do I
 understand what you guys talk about?  Somewhat.  Would I be able to help
 you in the development of the D language?  Only if it was in QA, most
 likely.

 Am I interested in this project?  You betcha.  I've got my hands in a
 couple dozen other projects, but I do want to follow this one, at least
 peripherally.

 I'll watch this thread for a few days, see what you guys think, and I'll
 keep in touch.  I hope I haven't insulted your intelligences with the
 above comments.  Bottom line is I like what I see, and I'd love to
 support you guys in building this language.  (No, not with money.  I
 don't have any.)

 Alex Vincent
 Vallejo, CA

Jan 11 2002
parent reply "Walter" <walter digitalmars.com> writes:
"J. Daniel Smith" <j_daniel_smith deja.com> wrote in message
news:a1n5rl$2g9q$1 digitaldaemon.com...
I haven't thought about this in near enough detail (remember, a
 "random thought") to say how it would work for everything, but the basic
 idea is that instead of writing HTML code like
     <code>
     void hello(int times)
     {
         int i;
         for (i = 0; i<times; i++)
         {
             printf("Hello World!\n");
         }
     }
     </code>
 you would instead write XML something like
     <d:function name="hello" type="void">
         <d:arg name="times" type="int" />
         <d:var name="i" type="int" />
         <dkwd:for init="i=0" test="i<times"; incr="i++">
             <d:call name="printf">
                 <d:param value="Hello World!\n" type="string" />
             </d:call>
         </dkwd:for>
     </d:function>

Er, I like the way the former looks better? <g>
Jan 11 2002
parent reply reiter nomadics.com (Mac Reiter) writes:
On Fri, 11 Jan 2002 16:59:10 -0800, "Walter" <walter digitalmars.com>
wrote:

"J. Daniel Smith" <j_daniel_smith deja.com> wrote in message
news:a1n5rl$2g9q$1 digitaldaemon.com...
I haven't thought about this in near enough detail (remember, a
 "random thought") to say how it would work for everything, but the basic
 idea is that instead of writing HTML code like
     <code>
     void hello(int times)
     {
         int i;
         for (i = 0; i<times; i++)
         {
             printf("Hello World!\n");
         }
     }
     </code>
 you would instead write XML something like
     <d:function name="hello" type="void">
         <d:arg name="times" type="int" />
         <d:var name="i" type="int" />
         <dkwd:for init="i=0" test="i<times"; incr="i++">
             <d:call name="printf">
                 <d:param value="Hello World!\n" type="string" />
             </d:call>
         </dkwd:for>
     </d:function>

Er, I like the way the former looks better? <g>

Agreed. The former is human-readable, HTML parse-able, and D compilable. The latter has none of those features directly, and only gains two of them after two extra components (the translation documents) are developed. I cannot imagine anyone developing code in the second style. If I had to do that, I would develop code in D, then write a translator to generate all the extra XML stuff. Why bother, if I can do the same for the first form by simply writing <code> and </code> around it? XML is good for what it was designed for -- taking one form of data and translating it into various other forms. But unless you can also make an XML translation that could output in some other language -- C++, Eiffel, Java -- then you gain nothing from the extra syntax. Mac
Jan 14 2002
parent reply "J. Daniel Smith" <j_daniel_smith deja.com> writes:
Well, I wasn't really thinking that someone would actually key in XML code
like that - it would more likely be the result of a "save as XML" operation
from an IDE.

The problem with a <code></code> block in HTML is that you end up doing
things like syntax coloring and pretty-printing yourself using HTML markup.
The sample from the D website is
    <br>
    <br>
        import Object;<br>
        import stdio;<br>
        <br>
        int <font size=+1><b>main</b></font>()<br>
        {   <br>
         &nbsp;<font color=red>printf</font>(<u>&quot;hello
world\n&quot;</u>);<br>
         &nbsp;return 0;<br>
        }<br>
    <br>
which contains no information about why "main" is bold or "printf" is red.
And heck, the HTML description doesn't even agree with the code ("Strings
can be displayed in green, comments in red, and keywords in boldface..."; we
have strings underlined (not green), function names (instead of keywords)
bold, and function calls (instead of comments) in red).  And what if I like
my comments green - if we're two different developers working on the same
HTML source file, one of us isn't going to be happy.

One of the ideals of XML is to seperate the data from the presentation; so
instead of writing
    int <font size=+1><b>main</b></font>()<br>{...}
for a function, you write
    <d:function name="main" type="int">...</d:function>
The D compiler could then use XSLT stylesheet to turn this into
    int main() {...}
when generating code; it is possible for XSLT to output something other than
another XML document.  And you get now easily generate HTML output to suit
your tastes - function names bold for example and comments green.

It is now also trivial to use the XML source file to gather statistics like
"how many functions are defined?", or code complexity metric such as "how
many keywords are used?" (I'm not saying these are particuarly good
metrics).  With the D code in an XML format, the source code itself can be
treated as data (without having to write a D parser).

There are an ever increasing number of tools available to process XML data;
the D/HTML integration is neat, but taking it to the next logical step (XML)
I think would open up a lot of possibilities that nobody has thought of yet.

   Dan


"Mac Reiter" <reiter nomadics.com> wrote in message
news:3c42f282.257783733 news.digitalmars.com...
 On Fri, 11 Jan 2002 16:59:10 -0800, "Walter" <walter digitalmars.com>
 wrote:

"J. Daniel Smith" <j_daniel_smith deja.com> wrote in message
news:a1n5rl$2g9q$1 digitaldaemon.com...
I haven't thought about this in near enough detail (remember, a
 "random thought") to say how it would work for everything, but the



 idea is that instead of writing HTML code like
     <code>
     void hello(int times)
     {
         int i;
         for (i = 0; i<times; i++)
         {
             printf("Hello World!\n");
         }
     }
     </code>
 you would instead write XML something like
     <d:function name="hello" type="void">
         <d:arg name="times" type="int" />
         <d:var name="i" type="int" />
         <dkwd:for init="i=0" test="i<times"; incr="i++">
             <d:call name="printf">
                 <d:param value="Hello World!\n" type="string" />
             </d:call>
         </dkwd:for>
     </d:function>

Er, I like the way the former looks better? <g>

Agreed. The former is human-readable, HTML parse-able, and D compilable. The latter has none of those features directly, and only gains two of them after two extra components (the translation documents) are developed. I cannot imagine anyone developing code in the second style. If I had to do that, I would develop code in D, then write a translator to generate all the extra XML stuff. Why bother, if I can do the same for the first form by simply writing <code> and </code> around it? XML is good for what it was designed for -- taking one form of data and translating it into various other forms. But unless you can also make an XML translation that could output in some other language -- C++, Eiffel, Java -- then you gain nothing from the extra syntax. Mac

Jan 14 2002
parent reply "Pavel Minayev" <evilone omen.ru> writes:
"J. Daniel Smith" <j_daniel_smith deja.com> wrote in message
news:a1v3rd$1e08$1 digitaldaemon.com...

 which contains no information about why "main" is bold or "printf" is red.
 And heck, the HTML description doesn't even agree with the code ("Strings
 can be displayed in green, comments in red, and keywords in boldface...";

 have strings underlined (not green), function names (instead of keywords)
 bold, and function calls (instead of comments) in red).  And what if I

 my comments green - if we're two different developers working on the same
 HTML source file, one of us isn't going to be happy.

Use HTML+CSS: <style> span.keyword { color: #0000ff; } span.number { color: #008000; } ... </style> <code> <span class="keyword">for</span>(int i = <span class="number">0</span>; ... </code> Yes, this is not very readable, and it's hard to write. But! 1) It is supposed to be viewed in the browser, and 2) It can be generated (see my D2HTML at http://d.batcave.net). And any browser with CSS support will render this correctly... I just don't understand, why use XML in area it wasn't designed for?
Jan 14 2002
parent reply "J. Daniel Smith" <j_daniel_smith deja.com> writes:
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.

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.

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.

Again, I really like the D/HTML idea; I just think that with an attempt at
tweaking in the XML direction all kinds of interesting things could be
possible.

   Dan

"Pavel Minayev" <evilone omen.ru> wrote in message
news:a1v5tl$1f7t$1 digitaldaemon.com...
 "J. Daniel Smith" <j_daniel_smith deja.com> wrote in message
 news:a1v3rd$1e08$1 digitaldaemon.com...

 which contains no information about why "main" is bold or "printf" is


 And heck, the HTML description doesn't even agree with the code


 can be displayed in green, comments in red, and keywords in


 we
 have strings underlined (not green), function names (instead of


 bold, and function calls (instead of comments) in red).  And what if I

 my comments green - if we're two different developers working on the


 HTML source file, one of us isn't going to be happy.

Use HTML+CSS: <style> span.keyword { color: #0000ff; } span.number { color: #008000; } ... </style> <code> <span class="keyword">for</span>(int i = <span class="number">0</span>; ... </code> Yes, this is not very readable, and it's hard to write. But! 1) It is supposed to be viewed in the browser, and 2) It can be generated (see my D2HTML at http://d.batcave.net). And any browser with CSS support will render this correctly... I just don't understand, why use XML in area it wasn't designed for?

Jan 15 2002
parent reply "Pavel Minayev" <evilone omen.ru> writes:
"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

 data.

What else could you it for? Programs are supposed to be compiled, at least I always thought so... =)
 With D2HTML, you have another program that does some (trival) parsing of a

 source file to generate HTML.  Not a big deal, but now you want to

 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

 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

 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.
Jan 15 2002
parent reply "OddesE" <OddesE_XYZ hotmail.com> writes:
"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


 than generating an OBJ file, you're treating the source not as code, but

 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

 source file to generate HTML.  Not a big deal, but now you want to

 a call graph: another program and another bunch of parsing.  Using XML


 XSLT you get a lot of this "for free", no need to write a program to


 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

 type of thing I have in mind, other than I think that a more rigorous


 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
Jan 17 2002
next sibling parent reply "Pavel Minayev" <evilone omen.ru> writes:
"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

 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

 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.
Jan 17 2002
next sibling parent "J. Daniel Smith" <j_daniel_smith deja.com> writes:
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

 dozen times and read a few hundred times. The point is that reading


 code is important and happens a lot. So source is not just supposed to


 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

 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


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

Jan 17 2002
prev sibling parent "Walter" <walter digitalmars.com> writes:
"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!
Jan 17 2002
prev sibling parent reply "J. Daniel Smith" <j_daniel_smith deja.com> writes:
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


 than generating an OBJ file, you're treating the source not as code,



 as
 data.

What else could you it for? Programs are supposed to be compiled, at


 I always thought so... =)

The average piece of source code is (re)written a few times, compiled a

 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

 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

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



 D
 source file to generate HTML.  Not a big deal, but now you want to

 a call graph: another program and another bunch of parsing.  Using XML


 XSLT you get a lot of this "for free", no need to write a program to


 a
 D source file.

Yes, but you have to get that XML first, noone is going to write


 in XML for you - so another parser and another generator... it'd


 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 -



 pretty much done the same thing with the <span> tags since you have a
 different "class" attribute for keywords, numbers, etc.  That's



 the
 type of thing I have in mind, other than I think that a more rigorous


 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

 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

 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.

 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

Jan 17 2002
parent reply "Sean L. Palmer" <spalmer iname.com> writes:
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

 about whitespace anyway, so it uses a different XSLT tranform to generate
 'void MyFunction(){printf("Hello World.\n");}'.

    Dan

Jan 17 2002
parent reply "OddesE" <OddesE_XYZ hotmail.com> writes:
"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,

 internally to some graph/tree format, convert to .html for pretty printed
 viewing in the editor, take changes made and reparse those sections into

 internal format, and when you hit Compile or Save it converts the tree

 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
Jan 18 2002
next sibling parent "Pavel Minayev" <evilone omen.ru> writes:
"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...
Jan 18 2002
prev sibling parent reply Russell Borogove <kaleja estarcion.com> writes:
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
Jan 18 2002
next sibling parent reply "Pavel Minayev" <evilone omen.ru> writes:
"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??? =)
Jan 18 2002
parent reply Russell Borogove <kaleja estarcion.com> writes:
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
Jan 18 2002
parent reply "Walter" <walter digitalmars.com> writes:
"Russell Borogove" <kaleja estarcion.com> wrote in message
news:3C48E461.6060708 estarcion.com...
 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.

I myself find it impossible to play with a language, I need a project to do with it. Perhaps you're the same way. I can list some projects <g>.
Feb 08 2002
parent Russell Borogove <kaleja estarcion.com> writes:
Walter wrote:

 "Russell Borogove" <kaleja estarcion.com> wrote in message
 news:3C48E461.6060708 estarcion.com...
 
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.

I myself find it impossible to play with a language, I need a project to do with it. Perhaps you're the same way. I can list some projects <g>.

Unfortunately, my brain got swallowed up by some audio DSP software projects, and unless I want to port the Steinberg VST API to D... hm, well, I suppose I could try... -Russell B
Feb 09 2002
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
"Russell Borogove" <kaleja estarcion.com> wrote in message
news:3C48B248.7070206 estarcion.com...
 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.

The trouble is, while the downloads of the compiler are very popular, too few wind up buying the CD to make it possible to hire someone. Should I start selling t-shirts? <g>
Feb 08 2002
parent reply "Pavel Minayev" <evilone omen.ru> writes:
"Walter" <walter digitalmars.com> wrote in message
news:a41oer$2se5$9 digitaldaemon.com...

 The trouble is, while the downloads of the compiler are very popular, too
 few wind up buying the CD to make it possible to hire someone.

 Should I start selling t-shirts? <g>

Yeah, a good idea. With D logo and the text "C++ suxx!" on the back =)
Feb 08 2002
parent reply Russell Borogove <kaleja estarcion.com> writes:
Pavel Minayev wrote:

 "Walter" <walter digitalmars.com> wrote in message
 news:a41oer$2se5$9 digitaldaemon.com...
 
 
The trouble is, while the downloads of the compiler are very popular, too
few wind up buying the CD to make it possible to hire someone.

Should I start selling t-shirts? <g>

Yeah, a good idea. With D logo and the text "C++ suxx!" on the back =)

Heh, I was thinking they should have the "Just what I need, another D in programming" quote. FWIW, if the T-shirt was reasonably cool-looking, preferably white on black to go with the rest of my wardrobe, I'd buy one. :) -RB
Feb 09 2002
parent reply "Pavel Minayev" <evilone omen.ru> writes:
"Russell Borogove" <kaleja estarcion.com> wrote in message
news:3C658E5D.9000004 estarcion.com...

 FWIW, if the T-shirt was reasonably cool-looking, preferably
 white on black to go with the rest of my wardrobe, I'd buy
 one. :)

Personally I'd prefer red on black, with a pentagram or two =)
Feb 09 2002
parent "Robert W. Cunningham" <rwc_2001 yahoo.com> writes:
Pavel Minayev wrote:

 "Russell Borogove" <kaleja estarcion.com> wrote in message
 news:3C658E5D.9000004 estarcion.com...

 FWIW, if the T-shirt was reasonably cool-looking, preferably
 white on black to go with the rest of my wardrobe, I'd buy
 one. :)

Personally I'd prefer red on black, with a pentagram or two =)

Cyan on magenta would rock. And be sure to enable blinking text! When conversation switches to T-shirts, the language must already be becoming a mainstream fad. Time to start working on D++. -BobC "The next thing you C will be D."
Feb 10 2002
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
"Alex Vincent" <jscript pacbell.net> wrote in message
news:3C3E994B.7020806 pacbell.net...
 First off,  let me point out one particular misconception on the D web
 site.  The <code>...</code> tag, like many HTML elements, provides
 little more than stylistic appearance.  It is NOT meant to contain live
 code, only examples thereof.  The more appropriate element would be
 <object>...</object>.  If you intend the code to be interpreted, perhaps
 a <script type="application/x-d">...</script> element would be

I did some research on this originally, and could find no official way of doing it. The <code> tag seemed like a good idea at the time.
 XML can handle scripting easily:  we simply use an
 <html:script>...</html:script> element.  The "html" part is an XML
 namespace.  I do not know how they relate to D or C++ namespaces.  But
 we typically define an XML namespace by using the prefix as a local name
 for an "xmlns" namespace:

 <root xmlns="http://digitalmars/xml-namespaces/root"
        xmlns:html="http://www.w3.org/1999/xhtml"
        >
 <html:script type="text/javascript">
 alert("Hello World")
 </html:script>
 </root>

 Similarly, you could use <html:object><html:param /></html:object>
 elements if you decided not to go the scripting route.

 XML also allows the use of processing instructions <?target data ?>,
 where target identifies the program supposed to execute the code.  PHP,
 for instance, uses <?php ?> (when you have the short form disabled).
 The data, for PHP anyway, indicates the code to execute.

I am clueless when it comes to XML ...
 Now, for a change of subject.  ECMAScript, popularly known by its
 Netscape-trademarked name JavaScript, and the W3C Document Object Model,
 are two of my favorite subjects.  (I wrote a whole book on them, and I
 still learn new facts quite often.)  I of course like the idea of mixing
 programming / scripting and markup languages together.

I'm very familiar with ECMAScript, as I've written an implementation of it. It runs 10-20x faster than JavaScript. <g>
 I alluded to using D as a scripting language for (X)HTML pages earlier.
   I wonder if anyone has a working example of this I could see.  I'll
 tell you, from a JavaScript developer's perspective, the concept of
 contracts just blew me away.  I'm very very impressed by that, and it's
 one thing I already wish JavaScript could support easily.  Alas...

I don't think D is suitable as a scripting language (I can get into why if you want).
 Personally, I'd go absolutely bonkers if someone could write an
 ECMAScript-compatible engine, like Mozilla.org's JavaScript1.5 beta
 engine.

Already done. I can send you an executable for it next week, and am looking for customers for it. It's a clean room implementation, so no IP problems, and includes Microsoft jscript extensions. It even can be plugged into Explorer.
  I don't know if you guys have been able to write a D compiler
 in D yet (I understand break-even is a very significant milestone),

No, it's in bootstrap mode in C++.
Jan 11 2002
next sibling parent "Pavel Minayev" <evilone omen.ru> writes:
"Walter" <walter digitalmars.com> wrote in message
news:a1o1hi$to$2 digitaldaemon.com...

 I don't think D is suitable as a scripting language (I can get into why if
 you want).

However a scripting language could be derived from D. Imagine ECMAScript, but with things like DBC, "stricter" classes (as seen in PHP), array slicing etc, borrowed from D - syntactically as well.
Jan 11 2002
prev sibling parent reply Alex Vincent <jscript pacbell.net> writes:
Walter wrote:
 I did some research on this originally,  and could find no official way of
 doing it. The <code> tag seemed like a good idea at the time.

No biggie. <object>...</object> is better, possibly with <param /> elements. That's all.
 I am clueless when it comes to XML ...

I'll be more than happy to help you.
 I'm very familiar with ECMAScript, as I've written an implementation of it.
 It runs 10-20x faster than JavaScript. <g>

Do you mean JS in the browser, or Mozilla.org's standalone JS Engine in C++?
 I don't think D is suitable as a scripting language (I can get into why if
 you want).

Please do. Incidentally, I like the way Pavel thinks in his reply to your thread...
 Already done. I can send you an executable for it next week, and am looking
 for customers for it. It's a clean room implementation, so no IP problems,
 and includes Microsoft jscript extensions. It even can be plugged into
 Explorer.

I'd love to get my hands on your implementation, see how it compares to the ECMAScript tests.
 No, it's in bootstrap mode in C++.

Let me guess: D in D is when you call it a "beta". 8-)
Jan 11 2002
parent reply "Walter" <walter digitalmars.com> writes:
"Alex Vincent" <jscript pacbell.net> wrote in message
news:3C3F9B97.20102 pacbell.net...
 I'm very familiar with ECMAScript, as I've written an implementation of


 It runs 10-20x faster than JavaScript. <g>

C++?

I ran it in the browser.
 I don't think D is suitable as a scripting language (I can get into why


 you want).

your thread...

Scripting languages are intended for short (less than 100 line) apps. As such, successful ones are typeless, have no declarations, don't import (everything is built in), has only a weak notion of scope, trades execution efficiency for economy of expression, and use dynamic binding. Scripts are great for binding a few lines of code to a button. Scripts don't scale well at all to large apps, or even medium apps. D, on the other hand, is strongly typed, is statically bound, is rather pointless for short apps, and is designed to scale easilly to very large programs.
 Already done. I can send you an executable for it next week, and am


 for customers for it. It's a clean room implementation, so no IP


 and includes Microsoft jscript extensions. It even can be plugged into
 Explorer.

the ECMAScript tests.

I'll send you an executable Monday.
 No, it's in bootstrap mode in C++.


Until D has been bootstrapped in multiple hosts, it'll remain in C++. Cross-compiling is too much of a pain <g>.
Jan 11 2002
parent reply Alex Vincent <jscript pacbell.net> writes:
Walter wrote:
 "Alex Vincent" <jscript pacbell.net> wrote in message
 news:3C3F9B97.20102 pacbell.net...
 
I'm very familiar with ECMAScript, as I've written an implementation of


It runs 10-20x faster than JavaScript. <g>

C++?

I ran it in the browser.

Okay. Generally the browser has some serious slowdowns due to other factors (processing alerts, JavaScript console messages, etc.) I'll have to see how it compares to the C++ engine, just for the fun of it.
 Scripting languages are intended for short (less than 100 line) apps. As
 such, successful ones are typeless, have no declarations, don't import
 (everything is built in), has only a weak notion of scope, trades execution
 efficiency for economy of expression, and use dynamic binding. Scripts are
 great for binding a few lines of code to a button. Scripts don't scale well
 at all to large apps, or even medium apps. D, on the other hand, is strongly
 typed, is statically bound, is rather pointless for short apps, and is
 designed to scale easilly to very large programs.

You might be surprised what they do with JavaScript in Mozilla / Netscape 6. Almost the whole mail/news application apparently runs on XUL (a non-standard XML language) and JavaScript. They also have a lot of JavaScripts which are over one thousand lines in length. I'm personally in the process of rebuilding a JavaScript I wrote a couple years ago specifically to handle arbitrary-precision numbers (think java.math.BigDecimal from the Java language). It's slow, but it gets the job done. It's also a rather large JavaScript, most of the work being done in functions. The last version I wrote (which I no longer have, sadly) had functions which themselves were easily more than 100 lines. As for a lot of your other objections, Waldemar Horwat's proposals for JavaScript2.0 seem to implement much of what you're talking about. At least, as far as I can tell. Plus, I've recently discovered -- and written an article on -- a feature of Mozilla-based browsers called JavaScript strict warnings. More than anything, they help us to reduce sloppiness and inefficiency in JavaScript code.
 I'll send you an executable Monday.

Great. Just one thing: does your version support watch() and unwatch(), or JavaScript1.5 getters and setters? You have no idea how many times I've cried for support of that in Internet Explorer.
Jan 11 2002
parent "Walter" <walter digitalmars.com> writes:
"Alex Vincent" <jscript pacbell.net> wrote in message
news:3C3FABD8.8040109 pacbell.net...
 Great.  Just one thing:  does your version support watch() and
 unwatch(), or JavaScript1.5 getters and setters?  You have no idea how
 many times I've cried for support of that in Internet Explorer.

No. It supports ECMA 3 with the extensions in Jscript. It does not support Netscape extensions, such as __proto__, etc. The longest ECMAScript app I've seen was 10,000 lines.
Jan 11 2002