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


I spend 3 hours to find a Dr Dobbs in France and bought a January one !
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


appropriate.

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


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






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


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.


Use HTML+CSS:

    <style>


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




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.


 Use HTML+CSS:

     <style>


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


as

 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


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




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


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


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




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


care

 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,


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


appropriate.

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.

 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 ran it in the browser.



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


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




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.


I'll send you an executable Monday.


 No, it's in bootstrap mode in C++.


 Let me guess:  D in D is when you call it a "beta".  8-)


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.
 

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