March 01, 2012
On 2/29/12 11:58 AM, Adam D. Ruppe wrote:
> Sorry if I sent twice, it is so easy to hit the
> wrong button on things.
>
> On Wednesday, 29 February 2012 at 17:32:42 UTC, Andrei Alexandrescu wrote:
>> So the idea is to make an entire subset of D convertible to Javascript?
>
> Yeah, and I'm pretty much there - I just built a
> little sort program with std.algorithm to it, which
> is pretty cool.

Saw that - pretty amazing.

The motivation sounds great. I think one area of focus going forward might be defining precisely the subset of D supported (e.g. I suppose pointer semantics would be difficult). I presume most of Safe D would be supported, but there's no formal definition of that either :o). Si this area is ripe for development.


Andrei


March 01, 2012
On 2/29/12 2:34 PM, Alex Rønne Petersen wrote:
> On 29-02-2012 18:32, Andrei Alexandrescu wrote:
>> On 2/26/12 9:51 PM, Adam D. Ruppe wrote:
>>> https://github.com/downloads/adamdruppe/dtojs/dtojs.zip
>> [snip]
>>
>> That's interesting. So the idea is to make an entire subset of D
>> convertible to Javascript?
>>
>> What use cases do you have in mind?
>>
>>
>> Andrei
>>
>
> Avoiding writing JS directly in web apps comes to mind.
>

I think it's cool you can convert D to JS, but I don't see why anyone would want to do it.

1. JS is a superior language: variables are dynamic and are not bound to just one single type during their lifetime. JS objects can store any property.
2. JS funcions are much easier to write (no need to declare types) and also to pass around (no need to write "&"). If you'd like to annotate variables, you could use Closure: https://developers.google.com/closure/compiler/docs/js-for-compiler
3. With JS you don't have to compile and run your code (well, I guess you could make something smart in D for that).
4. If you write JS you can debug it in the browser. No need to track back to the original source code.
5. If you don't like JS syntax or verbosity, you can use CoffeeScript, which is just a syntax rewriter, not a language/paradigm shift: http://coffeescript.org/
6. Javascript objects have some built-in properties that are different from D. So implementing those in D would make their performance worse (but you can always hard-code those functions into the compiler and translate them directly to their JS equivalent).

The good thing about writing in D is that you could probably get some IDE for autocompletion and such. You might also like to type things instead of using dynamic types.
March 01, 2012
On 03/01/2012 07:04 PM, Ary Manzana wrote:
>
> I think it's cool you can convert D to JS, but I don't see why anyone
> would want to do it.
>
> 1. JS is a superior language:
> [snip.]

Nope.
March 01, 2012
On 01-03-2012 19:04, Ary Manzana wrote:
> On 2/29/12 2:34 PM, Alex Rønne Petersen wrote:
>> On 29-02-2012 18:32, Andrei Alexandrescu wrote:
>>> On 2/26/12 9:51 PM, Adam D. Ruppe wrote:
>>>> https://github.com/downloads/adamdruppe/dtojs/dtojs.zip
>>> [snip]
>>>
>>> That's interesting. So the idea is to make an entire subset of D
>>> convertible to Javascript?
>>>
>>> What use cases do you have in mind?
>>>
>>>
>>> Andrei
>>>
>>
>> Avoiding writing JS directly in web apps comes to mind.
>>
>
> I think it's cool you can convert D to JS, but I don't see why anyone
> would want to do it.
>
> 1. JS is a superior language: variables are dynamic and are not bound to
> just one single type during their lifetime. JS objects can store any
> property.

You're arguing with a crowd gathered around a statically typed language. I think we can predict what this argument will lead to. :)

> 2. JS funcions are much easier to write (no need to declare types) and
> also to pass around (no need to write "&"). If you'd like to annotate
> variables, you could use Closure:
> https://developers.google.com/closure/compiler/docs/js-for-compiler

See the above.

> 3. With JS you don't have to compile and run your code (well, I guess
> you could make something smart in D for that).

? The D -> JS converter just translates it. It's no different from running e.g. the CoffeeScript compiler.

> 4. If you write JS you can debug it in the browser. No need to track
> back to the original source code.

Valid argument. Maybe we can make the D -> JS converter help in some way here?

> 5. If you don't like JS syntax or verbosity, you can use CoffeeScript,
> which is just a syntax rewriter, not a language/paradigm shift:
> http://coffeescript.org/

Don't even get me started on the horrible "features" in CoffeeScript. The guy who wrote the language literally had no clue what he was doing (he admitted to reading some "make your own language" book), and it isn't much better than JavaScript in terms of odd behavior and weird design decisions.

> 6. Javascript objects have some built-in properties that are different
> from D. So implementing those in D would make their performance worse
> (but you can always hard-code those functions into the compiler and
> translate them directly to their JS equivalent).

Can you be a little more specific here?

>
> The good thing about writing in D is that you could probably get some
> IDE for autocompletion and such. You might also like to type things
> instead of using dynamic types.

To be fair, excellent JS IDEs exist already; Visual Studio has great JS auto-completion, and ReSharper enhances it a lot too.

-- 
- Alex
March 01, 2012
On Thursday, 1 March 2012 at 18:56:07 UTC, Alex Rønne Petersen wrote:
> Valid argument. Maybe we can make the D -> JS converter help in some way here?

I don't know yet. assert() in your D code, while a far cry
from a real debugger, does have the decency to give file
and line number in your browser error log, like so:

Error: uncaught exception: tests.d:9 [object.AssertError] Assertion failure

in firefox, but it works in IE and I assume the others too.


Debugging in javascript is sure to be painful due to two
big facts though: 1) the line/file won't match up, and
2) the function and variable names are mangled, which gets
RIDICULOUSLY long in places, and very difficult to read.


For debugging, I might just put comments in the source
code.

/* file.d:30 */ var some_long_horrible_mangled_name = 20;

so at least you'd have a hope of reading it, by matching
it back up to your original source. This would be fairly
easy to implement and is better than nothing.



But, I don't know yet. For what I've done so far, a combination
of asserts and manually picking the generated code apart has
been what I use.
March 01, 2012
On Thursday, 1 March 2012 at 17:35:02 UTC, Andrei Alexandrescu wrote:
> The motivation sounds great. I think one area of focus going forward might be defining precisely the subset of D supported (e.g. I suppose pointer semantics would be difficult).

Right. I'm not sure exactly what is and is not @safe myself,
but I think *most* of it is realistic.

goto and pointers are the questionable ones right now. They
are solvable, but are they solvable in a way that I'm willing
to do? I don't want a while() { switch() { } } thing; the
code should look like javascript, not assembly.

Some integer semantics might be hard too. ubyte is ok, but byte
is different because 127+1 isn't as simple as x & 0xff

I'll have to think about that. Again, it surely *can*
be done, but I'd rather than an error than it generating
horribly inefficient javascript for simple operations.


But, everything else I've considered either already works
or is solvable with a little more time. It helps a lot
that dmd lowers a lot of the fancier things into simple
C-like constructs for me.


I just got scope guards working a few minutes ago, so
destructors can't be far behind.... then some bugs
on struct, and int math, goto, and pointer are the only
big rough spots left.


At least that I've thought of so far!
March 01, 2012
On Thursday, 1 March 2012 at 18:04:35 UTC, Ary Manzana wrote:
> 6. Javascript objects have some built-in properties that are different from D. So implementing those in D would make their performance worse (but you can always hard-code those functions into the compiler and translate them directly to their JS equivalent).


It's not so bad. In my zip, src/test/jslang provides bindings
to these things, which generate no code to use.

In src/test/std, I implement some Phobos interfaces this way.
(Run with dmd -inline and they generate no extra code.)

module std.string;

import jslang.string;

string replace(string a, string b, string c) {
   auto s = cast(JSString) a; // cast just to appease D
   return s.replace(b, c); // uses the built in method
}


...come to think of it, I think that's wrong. replace() in JS
only does the first occurrence iirc. D expects them all. But,
we could do:


import jslang.string;
import jslang.regexp;

string replace(string a, string b, string c) {
   auto s = cast(JSString) a; // cast just to appease D
   return s.replace(new RegExp(b, "g"), c); // uses the built in method
}

or something like that.




But, none of this is hard coded in the compiler. You can
call javascript functions just like anything else, given
a prototype.

Object eval(...); // don't bother typing the arguments if you don't want to
March 01, 2012
On 2012-03-01 16:07, Adam D. Ruppe wrote:
> On Thursday, 1 March 2012 at 07:14:02 UTC, Jacob Carlborg wrote:
>> BTW, how do you fit D's class based object model in JavaScript's
>> prototype based object model?
>
> Short answer is each D object in JS has a virtual
> function array and implements array as properties
> attached to the object. The JS constructor for the
> object populates these arrays.
>
> Virtual calls thus look like:
> obj._virtual_table[call_num]();
>
> instead of
> obj.function();
>
> It is similar in principle to how you'd implement
> it in C.
>
> Long answer:

Ok, I see. Thanks for the detailed explanation.

-- 
/Jacob Carlborg
March 01, 2012
On Thu, Mar 1, 2012 at 11:13 AM, Adam D. Ruppe <destructionator@gmail.com>wrote:
>
> Some integer semantics might be hard too. ubyte is ok, but byte is different because 127+1 isn't as simple as x & 0xff
>
> I'll have to think about that. Again, it surely *can*
> be done, but I'd rather than an error than it generating
> horribly inefficient javascript for simple operations.
>

Might TypedArrays help you implement some number type semantics? http://www.khronos.org/registry/typedarray/specs/latest/

--bb


March 01, 2012
On 2012-03-01 19:04, Ary Manzana wrote:
> On 2/29/12 2:34 PM, Alex Rønne Petersen wrote:
>> On 29-02-2012 18:32, Andrei Alexandrescu wrote:
>>> On 2/26/12 9:51 PM, Adam D. Ruppe wrote:
>>>> https://github.com/downloads/adamdruppe/dtojs/dtojs.zip
>>> [snip]
>>>
>>> That's interesting. So the idea is to make an entire subset of D
>>> convertible to Javascript?
>>>
>>> What use cases do you have in mind?
>>>
>>>
>>> Andrei
>>>
>>
>> Avoiding writing JS directly in web apps comes to mind.
>>
>
> I think it's cool you can convert D to JS, but I don't see why anyone
> would want to do it.
>
> 1. JS is a superior language: variables are dynamic and are not bound to
> just one single type during their lifetime. JS objects can store any
> property.

I really miss static typing sometimes in my day to day work (Ruby, JS, ...).

> 2. JS funcions are much easier to write (no need to declare types) and
> also to pass around (no need to write "&"). If you'd like to annotate
> variables, you could use Closure:
> https://developers.google.com/closure/compiler/docs/js-for-compiler

D's new lambda syntax is way more superior than the one in JS. Most of the times I would like to be able to specify types in function declarations.

> 3. With JS you don't have to compile and run your code (well, I guess
> you could make something smart in D for that).

True.

> 4. If you write JS you can debug it in the browser. No need to track
> back to the original source code.

True. But if you're compiler is good enough that won't be a problem, i.e. CoffeeScript.

> 5. If you don't like JS syntax or verbosity, you can use CoffeeScript,
> which is just a syntax rewriter, not a language/paradigm shift:
> http://coffeescript.org/

Already doing that. But if you're doing that you would most likley pre-compile it and have the same problems as 3. and 4.

> 6. Javascript objects have some built-in properties that are different
> from D. So implementing those in D would make their performance worse
> (but you can always hard-code those functions into the compiler and
> translate them directly to their JS equivalent).
>
> The good thing about writing in D is that you could probably get some
> IDE for autocompletion and such. You might also like to type things
> instead of using dynamic types.


-- 
/Jacob Carlborg