January 12, 2002
"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>.


January 12, 2002
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.

January 12, 2002
"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.


January 14, 2002
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
January 14, 2002
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


January 14, 2002
"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>
        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?



January 14, 2002
"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






January 15, 2002
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>
>         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?
>
>
>


January 15, 2002
"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.


January 17, 2002
"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