www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - I'd love to see DScript one day ...

reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/10/2016 3:55 AM, Chris wrote:
 Cool. I'd love to see `DScript` one day - and replace JS once and for all ...
 well ... just day dreaming ...
Dreams are reality: https://github.com/DigitalMars/DMDScript
Jun 10 2016
next sibling parent reply Jack Stouffer <jack jackstouffer.com> writes:
On Friday, 10 June 2016 at 22:01:53 UTC, Walter Bright wrote:
On 6/10/2016 3:55 AM, Chris wrote:
 Cool. I'd love to see `DScript` one day - and replace JS once 
 and for all ...
 well ... just day dreaming ...
Dreams are reality: https://github.com/DigitalMars/DMDScript
I have a feeling this will end up like your compiled Java story. Just my pessimism speaking.
Jun 10 2016
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Saturday, 11 June 2016 at 04:13:26 UTC, Jack Stouffer wrote:
 On Friday, 10 June 2016 at 22:01:53 UTC, Walter Bright wrote:
On 6/10/2016 3:55 AM, Chris wrote:
 Cool. I'd love to see `DScript` one day - and replace JS once 
 and for all ...
 well ... just day dreaming ...
Dreams are reality: https://github.com/DigitalMars/DMDScript
I have a feeling this will end up like your compiled Java story. Just my pessimism speaking.
Depends on whether it is conforming to edition 6. Modern frameworks use edition 6 or 5, and edition 6 may become ISO/IEC 16262:2016. For Go a similar project seems to be the most popular interpreter project: https://github.com/robertkrimen/otto Benchmarks, conformance comparisons?
Jun 10 2016
prev sibling next sibling parent poliklosio <poliklosio happypizza.com> writes:
On Friday, 10 June 2016 at 22:01:53 UTC, Walter Bright wrote:
 On 6/10/2016 3:55 AM, Chris wrote:
 Cool. I'd love to see `DScript` one day - and replace JS once
and for all ...
 well ... just day dreaming ...
Dreams are reality: https://github.com/DigitalMars/DMDScript
You have 2 readme files, so on github it looks like you have only one very short one (README.md) and that makes a poor impression.
Jun 11 2016
prev sibling next sibling parent reply Chris <wendlec tcd.ie> writes:
On Friday, 10 June 2016 at 22:01:53 UTC, Walter Bright wrote:
 On 6/10/2016 3:55 AM, Chris wrote:
 Cool. I'd love to see `DScript` one day - and replace JS once
and for all ...
 well ... just day dreaming ...
Dreams are reality: https://github.com/DigitalMars/DMDScript
Thanks for opening a new thread about this topic. Does DMDScript work with the latest version of D2? I once wanted to use DMDScript as a server side JS with vibe.d, but there were issues concerning versions of D etc. so I dropped the idea. However, with `DScript` I meant a new scripting language that can draw on the power of D, not necessarily a re-implementation of JS. Adam[1] and ketmar[2] have already worked on D based scripting languages. I wonder, if there is interest in creating a D-based (not `debased`) scripting language. D has features that are perfect for scripting or DS languages. Why not try something new? Having a child language might also help with D development in general, who knows. [1] Adam https://github.com/adamdruppe/arsd (jsvar.d, script.d) [2] ketmar http://repo.or.cz/dacs.git https://www.gnu.org/software/libjit/ http://repo.or.cz/gaemu.git
Jun 11 2016
next sibling parent reply qznc <qznc web.de> writes:
On Saturday, 11 June 2016 at 09:23:55 UTC, Chris wrote:
 On Friday, 10 June 2016 at 22:01:53 UTC, Walter Bright wrote:
 On 6/10/2016 3:55 AM, Chris wrote:
 Cool. I'd love to see `DScript` one day - and replace JS once
and for all ...
 well ... just day dreaming ...
Dreams are reality: https://github.com/DigitalMars/DMDScript
Thanks for opening a new thread about this topic. Does DMDScript work with the latest version of D2? I once wanted to use DMDScript as a server side JS with vibe.d, but there were issues concerning versions of D etc. so I dropped the idea. However, with `DScript` I meant a new scripting language that can draw on the power of D, not necessarily a re-implementation of JS. Adam[1] and ketmar[2] have already worked on D based scripting languages. I wonder, if there is interest in creating a D-based (not `debased`) scripting language. D has features that are perfect for scripting or DS languages. Why not try something new? Having a child language might also help with D development in general, who knows.
Do you want a scripting language in general or a browser language? I have given up hope for different browser languages than Javascript. The problem is not finding a language. A lot of people would love to have Lua, Python, or something else and it has not happened yet. Dart was the most serious attempt. They had full-time people at Google working on it and they gave up. The problem is that Javascript is tightly coupled to the DOM data structures. Disentangling that und inserting a layer in between there is the hard part. Oh, and you have to do this for all the major browser engines. If you just want to have a general purpose scripting language (e.g. for a game) you can use Lua, Javascript, TCL, and others already. How would you improve upon them?
Jun 11 2016
next sibling parent reply Chris <wendlec tcd.ie> writes:
On Saturday, 11 June 2016 at 10:14:25 UTC, qznc wrote:

 Do you want a scripting language in general or a browser 
 language?

 I have given up hope for different browser languages than 
 Javascript. The problem is not finding a language. A lot of 
 people would love to have Lua, Python, or something else and it 
 has not happened yet. Dart was the most serious attempt. They 
 had full-time people at Google working on it and they gave up. 
 The problem is that Javascript is tightly coupled to the DOM 
 data structures. Disentangling that und inserting a layer in 
 between there is the hard part. Oh, and you have to do this for 
 all the major browser engines.
No, JS is here to stay, unfortunately.
 If you just want to have a general purpose scripting language 
 (e.g. for a game) you can use Lua, Javascript, TCL, and others 
 already. How would you improve upon them?
Yep, something like that. We could look into what a scripting language based on D could offer that others can't - based on D's features. If you have an easy to use scripting language, people in science and data processing could use it for fast development. If speed is crucial, modules could be written in D or even C[1]. Just because we already have Python and Lua doesn't mean we shouldn't try to create another one. [1] Interfacing to C in Lua and Python is a bit annoying. `DScript` could offer both access to D and C. In fact, `DScript` could also interact with Lua and Python (cf. PyD and LuaD).
Jun 11 2016
next sibling parent reply ketmar <ketmar ketmar.no-ip.org> writes:
i'd also say: "JIT it from the start!" targeting LibJIT is very 
easy, and you will have nice machine code for x86, x86_64 and 
ARM, plus IR interpreter for any other "unsupported" arch.
Jun 11 2016
next sibling parent reply ketmar <ketmar ketmar.no-ip.org> writes:
p.s. i did a D wrapper for LibJIT, it is in DACS repo. i also 
talked with LibJIT maintainer, and that wrapper may be included 
in next LibJIT release.
Jun 11 2016
parent ketmar <ketmar ketmar.no-ip.org> writes:
p.p.s. i'm slowly working on my own SSA-based codegen library 
too. no timelines are set, tho.
Jun 11 2016
prev sibling parent Chris <wendlec tcd.ie> writes:
On Saturday, 11 June 2016 at 13:41:32 UTC, ketmar wrote:
 i'd also say: "JIT it from the start!" targeting LibJIT is very 
 easy, and you will have nice machine code for x86, x86_64 and 
 ARM, plus IR interpreter for any other "unsupported" arch.
Yes, I was thinking along the same lines. JIT from the start.
Jun 11 2016
prev sibling parent reply Jonathan Marler <johnnymarler gmail.com> writes:
On Saturday, 11 June 2016 at 10:34:41 UTC, Chris wrote:
 On Saturday, 11 June 2016 at 10:14:25 UTC, qznc wrote:

 [...]
No, JS is here to stay, unfortunately.
Good news, take a look at asmjs.org In the future you'll be able to compile your D code into javascript assembly, and run it in the browser. I predict LLVM will have a javascript assembly backend, so LDC would get this for free. Pretty cool stuff going on in the web world right now.
Jun 11 2016
parent Laeeth Isharc <laeeth laeethnospam.com> writes:
On Sunday, 12 June 2016 at 00:37:50 UTC, Jonathan Marler wrote:
 On Saturday, 11 June 2016 at 10:34:41 UTC, Chris wrote:
 On Saturday, 11 June 2016 at 10:14:25 UTC, qznc wrote:

 [...]
No, JS is here to stay, unfortunately.
Good news, take a look at asmjs.org In the future you'll be able to compile your D code into javascript assembly, and run it in the browser. I predict LLVM will have a javascript assembly backend, so LDC would get this for free. Pretty cool stuff going on in the web world right now.
Emscripten has been able to compile C++ to asm.js for a while - uses modified llvm back end and ported C runtime. I guess web assembly will take off, but somebody would still need to port the runtime for D and integrate with new llvm wasm back end when it is stable. See binaryem in meantime. I am not sure anyone is working on this for D currently, but we might put this up somewhere as a project in case volunteer comes along. Then when that's done still need to write a library to do web things like provide access to DOM from D. Emscripten already looks quite nice, and I was so wanting to be able to use it for serious work - it just doesn't seem to be there just yet. But I agree with your basic point, and it would be great not to have to write js.
Jun 11 2016
prev sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Saturday, 11 June 2016 at 10:14:25 UTC, qznc wrote:
 I have given up hope for different browser languages than 
 Javascript. The problem is not finding a language. A lot of 
 people would love to have Lua, Python, or something else and it 
 has not happened yet. Dart was the most serious attempt. They 
 had full-time people at Google working on it and they gave up.
They didn't give up as they use it internally for their advertising application. Dart 1.7 was out 2 days ago: http://news.dartlang.org/2016/06/dart-117-more-performance-improvements.html I think most people outside Google has given up though. I've picked up Typescript and I suspect many others have as well. Typescript is close enough to Javascript to make debugging reasonable.
Jun 11 2016
next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Saturday, 11 June 2016 at 18:36:23 UTC, Ola Fosheim Grøstad 
wrote:
 On Saturday, 11 June 2016 at 10:14:25 UTC, qznc wrote:
 I have given up hope for different browser languages than 
 Javascript. The problem is not finding a language. A lot of 
 people would love to have Lua, Python, or something else and 
 it has not happened yet. Dart was the most serious attempt. 
 They had full-time people at Google working on it and they 
 gave up.
They didn't give up as they use it internally for their advertising application. Dart 1.7 was out 2 days ago:
I meant Dart 1.17... Duh. Interestingly there was an interview related to Dart and Adwords UI http://news.dartlang.org/2016/03/the-new-adwords-ui-uses-dart-we-asked.html I found these quotes interesting: «One thing we found out was that developers preferred even stronger type checking than what Dart was providing. So, we are very excited about the work on Dart Strong Mode. We are also looking forward to cross-browser, fast edit refresh with the upcoming Dart Dev Compiler.» and «With Angular2, the application performance and code size are very similar between the JS and Dart versions. So any team considering Angular2 should consider Dart as well.» Dunno. Still not sure about the future of Dart, but stricter static typing is a good selling point.
Jun 11 2016
prev sibling parent qznc <qznc web.de> writes:
On Saturday, 11 June 2016 at 18:36:23 UTC, Ola Fosheim Grøstad 
wrote:
 On Saturday, 11 June 2016 at 10:14:25 UTC, qznc wrote:
 I have given up hope for different browser languages than 
 Javascript. The problem is not finding a language. A lot of 
 people would love to have Lua, Python, or something else and 
 it has not happened yet. Dart was the most serious attempt. 
 They had full-time people at Google working on it and they 
 gave up.
They didn't give up as they use it internally for their advertising application. Dart 1.7 was out 2 days ago: http://news.dartlang.org/2016/06/dart-117-more-performance-improvements.html
They gave up last year [0], when they abandoned Chrome-integration: “In order to do what’s best for our users and the web, and not just Google Chrome, we will focus our web efforts on compiling Dart to JavaScript,” Dart co-founders Lars Bak and Kasper Lund wrote today. “We have decided not to integrate the Dart VM into Chrome.” [0] http://news.dartlang.org/2015/03/dart-for-entire-web.html
Jun 11 2016
prev sibling next sibling parent Mike Parker <aldacron gmail.com> writes:
On Saturday, 11 June 2016 at 09:23:55 UTC, Chris wrote:

 However, with `DScript` I meant a new scripting language that 
 can draw on the power of D, not necessarily a re-implementation 
 of JS. Adam[1] and ketmar[2] have already worked on D based 
 scripting languages. I wonder, if there is interest in creating 
 a D-based (not `debased`) scripting language. D has features 
 that are perfect for scripting or DS languages. Why not try 
 something new? Having a child language might also help with D 
 development in general, who knows.
The source for the old MiniD language[1] is still available at DSource. Jarret moved on and converted it to C++ as Croc[2], but it might be an interesting project to get the old MiniD code compiling again as a starting point. [1] http://www.dsource.org/projects/minid/browser/trunk [2] https://github.com/JarrettBillingsley/Croc
Jun 11 2016
prev sibling parent reply Observer <here inter.net> writes:
On Saturday, 11 June 2016 at 09:23:55 UTC, Chris wrote:
 However, with `DScript` I meant a new scripting language that 
 can draw on the power of D, not necessarily a re-implementation 
 of JS. Adam[1] and ketmar[2] have already worked on D based 
 scripting languages. I wonder, if there is interest in creating 
 a D-based (not `debased`) scripting language. D has features 
 that are perfect for scripting or DS languages. Why not try 
 something new? Having a child language might also help with D 
 development in general, who knows.
I'm confused. I thought I read in TDPL (don't have it handy here to check) that you could just slap a shebang line on a D program and you then have a runnable script. Or something very close to that construction. So don't we already have what want?
Jun 11 2016
parent Basile B. <b2.temp gmx.com> writes:
On Saturday, 11 June 2016 at 17:18:59 UTC, Observer wrote:
 On Saturday, 11 June 2016 at 09:23:55 UTC, Chris wrote:
 However, with `DScript` I meant a new scripting language that 
 can draw on the power of D, not necessarily a 
 re-implementation of JS. Adam[1] and ketmar[2] have already 
 worked on D based scripting languages. I wonder, if there is 
 interest in creating a D-based (not `debased`) scripting 
 language. D has features that are perfect for scripting or DS 
 languages. Why not try something new? Having a child language 
 might also help with D development in general, who knows.
I'm confused. I thought I read in TDPL (don't have it handy here to check) that you could just slap a shebang line on a D program and you then have a runnable script. Or something very close to that construction. So don't we already have what want?
this way (she bang rdmd) is for turning a module into something like a shell script. You cannot use it dynamically in an application e.g with binding to the application variables and to the applications functions (like LUA in game or JS in web browsers).
Jun 11 2016
prev sibling next sibling parent reply yawniek <dlang srtnwz.com> writes:
On Friday, 10 June 2016 at 22:01:53 UTC, Walter Bright wrote:
 On 6/10/2016 3:55 AM, Chris wrote:
 Cool. I'd love to see `DScript` one day - and replace JS once
and for all ...
 well ... just day dreaming ...
Dreams are reality: https://github.com/DigitalMars/DMDScript
unfortunately this is unmaintained, has no docs and isn't working on linux/os x. having an ecma script implementation that is able to access D data would be very usefull for performant scripting.
Jun 11 2016
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/11/2016 3:07 AM, yawniek wrote:
 On Friday, 10 June 2016 at 22:01:53 UTC, Walter Bright wrote:
 On 6/10/2016 3:55 AM, Chris wrote:
 Cool. I'd love to see `DScript` one day - and replace JS once
and for all ...
 well ... just day dreaming ...
Dreams are reality: https://github.com/DigitalMars/DMDScript
unfortunately this is unmaintained,
It was working last year, when I got it up on Dub. Dmitry ported it to D2 a while ago. There has been a lack of interest in it, and so it doesn't get exercised much. But it is a fully functional implementation of Javascript. For anyone wanting to add a scripting language to, say, an IDE written in D, it would be ideal. It would also be ideal as a starting point if one wanted to invent yet another scripting language.
 has no docs
There is not much to document. Feed it a Javascript source file and it executes it.
 and isn't working on linux/os x.
http://bugzilla.digitalmars.com/issues/buglist.cgi?quicksearch=. It has in the past. Probably something trivial.
 having an ecma script implementation that is able to access D data would be
very
 usefull
 for performant scripting.
Pull requests are welcome.
Jun 11 2016
parent Michael <michael toohuman.io> writes:
Having DScript running in the browser and D on the server would 
be an absolute dream to develop with. It might also turn a few 
heads our way.
Jun 11 2016
prev sibling parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On 11-Jun-2016 13:07, yawniek wrote:
 On Friday, 10 June 2016 at 22:01:53 UTC, Walter Bright wrote:
 On 6/10/2016 3:55 AM, Chris wrote:
 Cool. I'd love to see `DScript` one day - and replace JS once
and for all ...
 well ... just day dreaming ...
Dreams are reality: https://github.com/DigitalMars/DMDScript
unfortunately this is unmaintained, has no docs and isn't working on linux/os x. having an ecma script implementation that is able to access D data would be very usefull for performant scripting.
The only problem I'm aware of is that it's that 64bit are not supported yet. -- Dmitry Olshansky
Jun 13 2016
prev sibling next sibling parent reply Dicebot <public dicebot.lv> writes:
On 06/11/2016 01:01 AM, Walter Bright wrote:
 On 6/10/2016 3:55 AM, Chris wrote:
 Cool. I'd love to see `DScript` one day - and replace JS once and for
all ...
 well ... just day dreaming ...
Dreams are reality: https://github.com/DigitalMars/DMDScript
On a related topic - has anyone looked into what needs to be done to support D + WebAssembly combo?
Jun 12 2016
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Sunday, 12 June 2016 at 08:32:10 UTC, Dicebot wrote:
 On 06/11/2016 01:01 AM, Walter Bright wrote:
 On 6/10/2016 3:55 AM, Chris wrote:
 Cool. I'd love to see `DScript` one day - and replace JS once 
 and for
all ...
 well ... just day dreaming ...
Dreams are reality: https://github.com/DigitalMars/DMDScript
On a related topic - has anyone looked into what needs to be done to support D + WebAssembly combo?
WebAssembly is currently close to asm.js. In fact I believe WebAssembly is distilled from the asm.js backend. Single threaded, no garbage collection support.
Jun 12 2016
prev sibling next sibling parent data man <datamanrb gmail.com> writes:
On Friday, 10 June 2016 at 22:01:53 UTC, Walter Bright wrote:
 On 6/10/2016 3:55 AM, Chris wrote:
 Cool. I'd love to see `DScript` one day - and replace JS once
and for all ...
 well ... just day dreaming ...
My crazy dream (or cool idea :): to use the DMD interpreter as the script engine!
Jun 12 2016
prev sibling parent reply Chris <wendlec tcd.ie> writes:
On Friday, 10 June 2016 at 22:01:53 UTC, Walter Bright wrote:
 On 6/10/2016 3:55 AM, Chris wrote:
 Cool. I'd love to see `DScript` one day - and replace JS once
and for all ...
 well ... just day dreaming ...
Dreams are reality: https://github.com/DigitalMars/DMDScript
I just tried to compile it on Linux with dmd v2.071.0 in 64bit mode. The compiler emits loads of deprecation warnings concerning module import, and it seems to be geared towards 32bit: [...] engine/source/dmdscript/dstring.d(953,16): Deprecation: module std.string is not accessible here, perhaps add 'static import std.string;' engine/source/dmdscript/expression.d(216,9): Warning: statement is not reachable engine/source/dmdscript/expression.d(306,28): Deprecation: module std.ascii is not accessible here, perhaps add 'static import std.ascii;' engine/source/dmdscript/expression.d(318,9): Error: static assert (8LU == 4LU) is false dmd failed with exit code 1. The error message refers to: ` override void toIR(IRstate *irs, uint ret) { static assert((Identifier*).sizeof == uint.sizeof); // <====== if(ret) { uint u = cast(uint)Identifier.build(string); irs.gen2(loc, IRstring, ret, u); } } `
Jun 12 2016
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/12/2016 3:17 AM, Chris wrote:
 On Friday, 10 June 2016 at 22:01:53 UTC, Walter Bright wrote:
 On 6/10/2016 3:55 AM, Chris wrote:
 Cool. I'd love to see `DScript` one day - and replace JS once
and for all ...
 well ... just day dreaming ...
Dreams are reality: https://github.com/DigitalMars/DMDScript
I just tried to compile it on Linux with dmd v2.071.0 in 64bit mode. The compiler emits loads of deprecation warnings concerning module import,
Yeah, the import lookup was recently changed.
 and it seems to be geared towards 32bit:
That's right. It should be fixed. Nevertheless, these are minor issues. If you try to create a new script compiler, you're in for a heluva lot more work than fixing some bit rot.
Jun 12 2016
parent reply Chris <wendlec tcd.ie> writes:
On Sunday, 12 June 2016 at 10:51:16 UTC, Walter Bright wrote:
 On 6/12/2016 3:17 AM, Chris wrote:
 On Friday, 10 June 2016 at 22:01:53 UTC, Walter Bright wrote:
 On 6/10/2016 3:55 AM, Chris wrote:
 Cool. I'd love to see `DScript` one day - and replace JS 
 once
and for all ...
 well ... just day dreaming ...
Dreams are reality: https://github.com/DigitalMars/DMDScript
I just tried to compile it on Linux with dmd v2.071.0 in 64bit mode. The compiler emits loads of deprecation warnings concerning module import,
Yeah, the import lookup was recently changed.
 and it seems to be geared towards 32bit:
That's right. It should be fixed. Nevertheless, these are minor issues. If you try to create a new script compiler, you're in for a heluva lot more work than fixing some bit rot.
Sure, but then we should turn it into a first class citizen and update it with each version of dmd and prevent bit rot. I haven't had a chance to look at the source code in detail yet. How hard would it be to integrate JIT and D (and C) interop? Theoretically something like the Derelict-D libs allow for interop with Python and Lua too. I think we could create something really nice and useful here. By the way, provided we go ahead with this, wouldn't the name DScript be catchier than DMSScript? Although I don't want to bikeshed about the name now.
Jun 12 2016
next sibling parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Sunday, 12 June 2016 at 11:23:56 UTC, Chris wrote:
 I haven't had a chance to look at the source code in detail 
 yet. How hard would it be to integrate JIT and D (and C) 
 interop?
not hard. there is extension example (extending engine with D). also, the engine compiles scripts to IR code, which can be JITed as is, or used as a base for some other code representation. the worst thing (for me) is that it is javascript.
Jun 12 2016
parent reply Chris <wendlec tcd.ie> writes:
On Sunday, 12 June 2016 at 11:58:08 UTC, ketmar wrote:
 On Sunday, 12 June 2016 at 11:23:56 UTC, Chris wrote:
 I haven't had a chance to look at the source code in detail 
 yet. How hard would it be to integrate JIT and D (and C) 
 interop?
not hard. there is extension example (extending engine with D). also, the engine compiles scripts to IR code, which can be JITed as is, or used as a base for some other code representation. the worst thing (for me) is that it is javascript.
Yeah, same here! It'd be best to write a proper scripting language based on DMDScript.
Jun 12 2016
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Sunday, 12 June 2016 at 12:13:45 UTC, Chris wrote:
 On Sunday, 12 June 2016 at 11:58:08 UTC, ketmar wrote:
 On Sunday, 12 June 2016 at 11:23:56 UTC, Chris wrote:
 I haven't had a chance to look at the source code in detail 
 yet. How hard would it be to integrate JIT and D (and C) 
 interop?
not hard. there is extension example (extending engine with D). also, the engine compiles scripts to IR code, which can be JITed as is, or used as a base for some other code representation. the worst thing (for me) is that it is javascript.
Yeah, same here! It'd be best to write a proper scripting language based on DMDScript.
Well, ES6 is actually reasonably ok. It has both generators and WeakSet (set of objects that is pruned if the object is collected and many many other improvements: http://es6-features.org/
Jun 12 2016
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Sunday, 12 June 2016 at 12:25:00 UTC, Ola Fosheim Grøstad 
wrote:
 Well, ES6 is actually reasonably ok.
js is fubared from the start. there is no need to follow the broken path.
Jun 12 2016
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Sunday, 12 June 2016 at 12:30:46 UTC, ketmar wrote:
 js is fubared from the start. there is no need to follow the 
 broken path.
Whatever, the core of JavaScript is close to Self: https://en.wikipedia.org/wiki/Self_(programming_language) JavaScript was just messy in the details. ES6 is fixing a lot of that.
Jun 12 2016
prev sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Sunday, 12 June 2016 at 11:23:56 UTC, Chris wrote:
 I haven't had a chance to look at the source code in detail 
 yet. How hard would it be to integrate JIT and D (and C) 
 interop? Theoretically something like the Derelict-D libs allow 
 for interop with Python and Lua too. I think we could create 
 something really nice and useful here.
I don't think JIT is needed to be useful. Conformance would be more important so that you can use libraries and compilers that compile to EcmaScript. But conformance to EcmasScript 6 is a big big big big job. http://www.ecma-international.org/ecma-262/6.0/
Jun 12 2016
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Sunday, 12 June 2016 at 12:05:49 UTC, Ola Fosheim Grøstad 
wrote:
 Conformance would be more important so that you can
 use libraries and compilers that compile to EcmaScript.
That's kinda the problem with dmdscript: it is an excellent and conformant implementation of Javascript that performed better than its competitors... many years ago. The standard has moved on, the bar on performance has raised, and dmdscript hasn't even kept up with changes in D. It's still a very good implementation of ECMAScript 3, and with a bit of D stuff, interfacing with it is reasonably easy, but tbh it just isn't something I'd use anymore... my script.d is easier to build and interface for quick toys, and one of the newer JS engines is better at Javascript itself.
Jun 12 2016
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Sunday, 12 June 2016 at 12:42:23 UTC, Adam D. Ruppe wrote:
 The standard has moved on, the bar on performance has raised, 
 and dmdscript hasn't even kept up with changes in D.
Not too worried about the performance, but EcmaScript 6 has increased the feature set so much that the spec is over twice as large as for EcmaScript 5... And Chrome 52 is apparently shipping with both ES6 and some ES7, so it will be hard to keep up.
Jun 12 2016
parent reply Chris <wendlec tcd.ie> writes:
On Sunday, 12 June 2016 at 21:32:18 UTC, Ola Fosheim Grøstad 
wrote:
 On Sunday, 12 June 2016 at 12:42:23 UTC, Adam D. Ruppe wrote:
 The standard has moved on, the bar on performance has raised, 
 and dmdscript hasn't even kept up with changes in D.
Not too worried about the performance, but EcmaScript 6 has increased the feature set so much that the spec is over twice as large as for EcmaScript 5... And Chrome 52 is apparently shipping with both ES6 and some ES7, so it will be hard to keep up.
Seems like it's a dead race. DMDScript has been in the attic for too long. Trying to play catch up with Google, an Internet company, seems hardly worth the effort.
Jun 13 2016
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/13/2016 2:21 AM, Chris wrote:
 Seems like it's a dead race. DMDScript has been in the attic for too long.
 Trying to play catch up with Google, an Internet company, seems hardly worth
the
 effort.
For making your own browser, probably right. For adding scripting support to an IDE, anything with plugins, etc., it's quite good for the job. Regardless, you're way ahead with DMDScript than starting from scratch.
Jun 13 2016
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Monday, 13 June 2016 at 20:19:37 UTC, Walter Bright wrote:
 Regardless, you're way ahead with DMDScript than starting from 
 scratch.
it heavily depends of what exactly one want and how. by the time i'll fully understand DMDScript code, i'd complete my own implementation of dynamic scripting language with JIT.
Jun 13 2016
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/13/2016 2:13 PM, ketmar wrote:
 it heavily depends of what exactly one want and how. by the time i'll fully
 understand DMDScript code, i'd complete my own implementation of dynamic
 scripting language with JIT.
Remember you also have to write the documentation for your own language, and write your own test suite. With Javascript you can rely on existing documentation and test suites, which are enormous time savers.
Jun 13 2016
next sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Mon, Jun 13, 2016 at 04:47:40PM -0700, Walter Bright via Digitalmars-d wrote:
 On 6/13/2016 2:13 PM, ketmar wrote:
 it heavily depends of what exactly one want and how. by the time
 i'll fully understand DMDScript code, i'd complete my own
 implementation of dynamic scripting language with JIT.
Remember you also have to write the documentation for your own language, and write your own test suite. With Javascript you can rely on existing documentation and test suites, which are enormous time savers.
My *real* dream is for D (or some suitable subset thereof) to replace Javascript in browsers. But that's a very distant, if at all even possible, dream. :-D T -- I am not young enough to know everything. -- Oscar Wilde
Jun 13 2016
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/13/2016 5:13 PM, H. S. Teoh via Digitalmars-d wrote:
 My *real* dream is for D (or some suitable subset thereof) to replace
 Javascript in browsers.  But that's a very distant, if at all even
 possible, dream. :-D
It's a great dream!
Jun 13 2016
parent reply Yuxuan Shui <yshuiv7 gmail.com> writes:
On Tuesday, 14 June 2016 at 00:55:52 UTC, Walter Bright wrote:
 On 6/13/2016 5:13 PM, H. S. Teoh via Digitalmars-d wrote:
 My *real* dream is for D (or some suitable subset thereof) to 
 replace
 Javascript in browsers.  But that's a very distant, if at all 
 even
 possible, dream. :-D
It's a great dream!
Don't we have a pretty efficient JIT javascript implementation in D already? https://github.com/higgsjs/Higgs
Jun 13 2016
next sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Tue, Jun 14, 2016 at 01:36:48AM +0000, Yuxuan Shui via Digitalmars-d wrote:
 On Tuesday, 14 June 2016 at 00:55:52 UTC, Walter Bright wrote:
 On 6/13/2016 5:13 PM, H. S. Teoh via Digitalmars-d wrote:
 My *real* dream is for D (or some suitable subset thereof) to
 replace Javascript in browsers.  But that's a very distant, if at
 all even possible, dream. :-D
It's a great dream!
Don't we have a pretty efficient JIT javascript implementation in D already? https://github.com/higgsjs/Higgs
I know that. What I meant was that instead of writing javascript we'd write D instead, in our webpages. Or at least, some subset of D that's safe for the web. I.e., instead of: <html><head> <script type="text/javascript" src="myscript.js"/> ... you'd write <html><head> <script type="text/d" src="myscript.d"/> ... It's unlikely to happen in the near future, though, if at all. But one can dream. :-) T -- Computers shouldn't beep through the keyhole.
Jun 13 2016
next sibling parent reply dewitt <dkdewitt gmail.com> writes:
On Tuesday, 14 June 2016 at 03:31:10 UTC, H. S. Teoh wrote:
 On Tue, Jun 14, 2016 at 01:36:48AM +0000, Yuxuan Shui via 
 Digitalmars-d wrote:
 On Tuesday, 14 June 2016 at 00:55:52 UTC, Walter Bright wrote:
 On 6/13/2016 5:13 PM, H. S. Teoh via Digitalmars-d wrote:
 My *real* dream is for D (or some suitable subset thereof) 
 to replace Javascript in browsers.  But that's a very 
 distant, if at all even possible, dream. :-D
It's a great dream!
Don't we have a pretty efficient JIT javascript implementation in D already? https://github.com/higgsjs/Higgs
I know that. What I meant was that instead of writing javascript we'd write D instead, in our webpages. Or at least, some subset of D that's safe for the web. I.e., instead of: <html><head> <script type="text/javascript" src="myscript.js"/> ... you'd write <html><head> <script type="text/d" src="myscript.d"/> ... It's unlikely to happen in the near future, though, if at all. But one can dream. :-) T
I know its a dream but really whats wrong with JS in the browser? Now with no need for JQuery and ES6 its not really that bad. Better to use it for a scripting lang and other things. My opinion only.. If were dreamin Id rather see the next Kafka or Elasticsearch big idea written in D...
Jun 13 2016
parent reply Dicebot <public dicebot.lv> writes:
On 06/14/2016 07:09 AM, dewitt wrote:
 I know its a dream but really whats wrong with JS in the browser?  Now
 with no need for JQuery and ES6 its not really that bad.  Better to use
 it for a scripting lang and other things.  My opinion only..  If were
 dreamin Id rather see the next Kafka or Elasticsearch big idea written
 in D...
Because for some people static typing and compile-time checking is not a burden but a great help in designing bug-free programs. And if you stand by those values, JS is absolutely terrible language no matter the domain (it drives me mad every time I have to touch it).
Jun 14 2016
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/14/2016 11:55 AM, Dicebot wrote:
 Because for some people static typing and compile-time checking is not a
 burden but a great help in designing bug-free programs. And if you stand
 by those values, JS is absolutely terrible language no matter the domain
 (it drives me mad every time I have to touch it).
I find a typeless language convenient when it's less than one screen in size. Their advantages fall away when things get larger. I don't know how people cope with a large project in a dynamic language.
Jun 14 2016
next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Tuesday, 14 June 2016 at 21:23:38 UTC, Walter Bright wrote:
 I find a typeless language convenient when it's less than one 
 screen in size. Their advantages fall away when things get 
 larger. I don't know how people cope with a large project in a 
 dynamic language.
By adding asserts, testing, logging and if available: static analysis. :-) Just adding an assert can help a lot on static analysis. But I'd say that gradual typing is a pretty nice tradeoff. It is faster to iterate without all the typing syntax, and then you can add the types when you are happy with the result. Although the best solution would probably be to throw a "switch" on the static analysis before release so that all undecided types (not able to deduce it by static analysis) are caught before the program is shipped.
Jun 15 2016
prev sibling parent reply Chris <wendlec tcd.ie> writes:
On Tuesday, 14 June 2016 at 21:23:38 UTC, Walter Bright wrote:
 On 6/14/2016 11:55 AM, Dicebot wrote:

 I find a typeless language convenient when it's less than one 
 screen in size. Their advantages fall away when things get 
 larger. I don't know how people cope with a large project in a 
 dynamic language.
In the long run the disadvantages of dynamic languages outweigh the advantages. There is the issue of redefining variables and values. It can introduce subtle bugs that are hard to find. You spend a lot of time debugging stuff that would have easily been caught in a static language. Stuff like this is not uncommon: `# example.py name = "Walter" print(name) name = ["Walter"] if len(name) == 1: print("Your name has length 1") ` It prints `Walter Your name has length 1 ` Horrible!
Jun 15 2016
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Wednesday, 15 June 2016 at 08:48:19 UTC, Chris wrote:
 On Tuesday, 14 June 2016 at 21:23:38 UTC, Walter Bright wrote:
 On 6/14/2016 11:55 AM, Dicebot wrote:

 I find a typeless language convenient when it's less than one 
 screen in size. Their advantages fall away when things get 
 larger. I don't know how people cope with a large project in a 
 dynamic language.
In the long run the disadvantages of dynamic languages outweigh the advantages. There is the issue of redefining variables and values. It can introduce subtle bugs that are hard to find. You spend a lot of time debugging stuff that would have easily been caught in a static language. Stuff like this is not uncommon: `# example.py name = "Walter" print(name) name = ["Walter"] if len(name) == 1: print("Your name has length 1") `
This isn't related to dynamic typing. It is related to variable assignment with implicit declaration and initialization. Conceptually you would have the same problem in C++ and D since they both use duck-typing (e.g. both overloading and templates are essentially providing duck-typing).
Jun 15 2016
parent reply Chris <wendlec tcd.ie> writes:
On Wednesday, 15 June 2016 at 09:09:42 UTC, Ola Fosheim Grøstad 
wrote:
 This isn't related to dynamic typing. It is related to variable 
 assignment with implicit declaration and initialization.
But this is part of the definition of a dynamic language, isn't it?
 Conceptually you would have the same problem in C++ and D since 
 they both use duck-typing (e.g. both overloading and templates 
 are essentially providing duck-typing).
But factually I don't: ` import std.stdio; void main() { auto name = "Walter"; writeln(name); name = ["Walter"]; } ` Error: cannot implicitly convert expression (["Walter"]) of type string[] to string
Jun 15 2016
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Wednesday, 15 June 2016 at 09:40:39 UTC, Chris wrote:
 But factually I don't:
That's just because your example isn't realistic. A realistic case in Python etc is where you accidentally assign when you wanted to introduce a new symbol. That is not a typing issue. A realistic D/C++ scenario: import std.stdio; // imported from libraries: auto create_name(string n){ return ["PersonName",n]; } auto create_name(const(char)* n){ import core.stdc.string: strlen; auto slice = n[0 .. strlen(n)]; return slice.dup; } void main(){ auto myname = create_name("Ola"); writeln("Letter count: ", myname.length); }
Jun 15 2016
parent Chris <wendlec tcd.ie> writes:
On Wednesday, 15 June 2016 at 10:08:41 UTC, Ola Fosheim Grøstad 
wrote:
 That's just because your example isn't realistic. A realistic 
 case in Python etc is where you accidentally assign when you 
 wanted to introduce a new symbol. That is not a typing issue.

 A realistic D/C++ scenario:

 import std.stdio;
 // imported from libraries:

 auto create_name(string n){
 	return ["PersonName",n];
 }

 auto create_name(const(char)* n){
 	import core.stdc.string: strlen;
 	auto slice = n[0 .. strlen(n)];
 	return slice.dup;
 }


 void main(){
      auto myname = create_name("Ola");
      writeln("Letter count: ", myname.length);
 }
It's much harder to shoot yourself in the foot, though: ` auto create_name(string n) { return ["PersonName",n]; } auto create_name(const(char)* n) { import core.stdc.string: strlen; auto slice = n[0 .. strlen(n)]; return slice.dup; } void main() { auto myname = create_name("Ola"); writeln("Letter count: ", myname.length); auto p = Person(); p.firstName = myname; writeln(p.firstName); } struct Person { char[] firstName; char[] secondName; } ` Error: cannot implicitly convert expression (myname) of type string[] to char[] If you have ` void main() { import std.conv : to; auto myname = create_name("Ola"); writeln("Letter count: ", myname.length); auto p = Person(); p.firstName = to!string(myname); writeln(p.firstName); } struct Person { string firstName; string secondName; } ` Then you will convert `string[]` into the string `["PersonName", "Ola"]`, and you have a bug. However, factually, I hardly ever encounter bugs like this, whereas in Python this happens quite a lot once you deal with more than one module.
Jun 15 2016
prev sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Wednesday, 15 June 2016 at 09:40:39 UTC, Chris wrote:
 On Wednesday, 15 June 2016 at 09:09:42 UTC, Ola Fosheim Grøstad 
 wrote:
 This isn't related to dynamic typing. It is related to 
 variable assignment with implicit declaration and 
 initialization.
But this is part of the definition of a dynamic language, isn't it?
Sorry, I missed this question. No, some languages distinguish by requiring you to use special syntax like "let x = 4" for introducing the name "x" and so on. Some languages also allow you to freeze a variable so it becomes constant. There is a pretty large space of different semantics to choose from.
Jun 15 2016
parent reply Chris <wendlec tcd.ie> writes:
On Wednesday, 15 June 2016 at 10:27:14 UTC, Ola Fosheim Grøstad 
wrote:
 Sorry, I missed this question.

 No, some languages distinguish by requiring you to use special 
 syntax like "let x = 4" for introducing the name "x" and so on.

 Some languages also allow you to freeze a variable so it 
 becomes constant.

 There is a pretty large space of different semantics to choose 
 from.
But Python for example doesn't care. What you describe is basically trying to mimic static typing.
Jun 15 2016
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Wednesday, 15 June 2016 at 11:33:23 UTC, Chris wrote:
 But Python for example doesn't care.
Python is fairly dynamic and static analysis tools such as PyCharm helps a lot when you write larger Python projects.
 What you describe is basically trying to mimic static typing.
No, you can have something like this: var x = f(42); if(x>100) freeze x; // whether x is immutable or not is not statically known at this point
Jun 15 2016
parent reply Chris <wendlec tcd.ie> writes:
On Wednesday, 15 June 2016 at 12:14:45 UTC, Ola Fosheim Grøstad 
wrote:
 On Wednesday, 15 June 2016 at 11:33:23 UTC, Chris wrote:
 But Python for example doesn't care.
Python is fairly dynamic and static analysis tools such as PyCharm helps a lot when you write larger Python projects.
 What you describe is basically trying to mimic static typing.
No, you can have something like this: var x = f(42); if(x>100) freeze x; // whether x is immutable or not is not statically known at this point
But 'freezing' ain't got nothing to do with the type. It's basically D's `immutable`. In my experience, statically typed languages prevent a lot of silly and time consuming bugs by simply checking the type. If, after a few changes, function arguments don't match, the compiler (or interpreter) complains immediately. In Python the code may still work: ` def loophere(variable): for i in variable: print (i) loopy = "Ola, mundo!" loophere(loopy) # Developer decides that `loopy` should be a list of strings loopy = ["Ola", "mundo", "!"] loophere(loopy) `
Jun 15 2016
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Wednesday, 15 June 2016 at 13:17:46 UTC, Chris wrote:
 In my experience, statically typed languages prevent a lot of 
 silly and time consuming bugs by simply checking the type.
Yes, but I would put it more generally. Matching a program against a specification of constraints prevents a set of runtime errors and bugs. But providing the specification is also tedious. You can have much stronger static verification of constraints than in C++/D. For instance check the various legal states and what transitions you can have between them. I am certainly in favour of more static checks, but I am pleasantly surprised at what can be achieved with optional static analysis.
Jun 15 2016
prev sibling next sibling parent reply cym13 <cpicard openmailbox.org> writes:
On Tuesday, 14 June 2016 at 03:31:10 UTC, H. S. Teoh wrote:
 On Tue, Jun 14, 2016 at 01:36:48AM +0000, Yuxuan Shui via 
 Digitalmars-d wrote:
 On Tuesday, 14 June 2016 at 00:55:52 UTC, Walter Bright wrote:
 On 6/13/2016 5:13 PM, H. S. Teoh via Digitalmars-d wrote:
 My *real* dream is for D (or some suitable subset thereof) 
 to replace Javascript in browsers.  But that's a very 
 distant, if at all even possible, dream. :-D
It's a great dream!
Don't we have a pretty efficient JIT javascript implementation in D already? https://github.com/higgsjs/Higgs
I know that. What I meant was that instead of writing javascript we'd write D instead, in our webpages. Or at least, some subset of D that's safe for the web. I.e., instead of: <html><head> <script type="text/javascript" src="myscript.js"/> ... you'd write <html><head> <script type="text/d" src="myscript.d"/> ... It's unlikely to happen in the near future, though, if at all. But one can dream. :-) T
I love D but I don't see the point of putting it directly in a browser. It's main forces (compile-time stuff and speed) would have no impact at all and the static typing would just make it harder for no good reason. The web is a very dynamic place so I'd rather have a very dynamic language. Maybe not javascript but really no D. Let's keep D where it's strong and accept that it can't be strong at everything and that other languages are better suited for the task.
Jun 13 2016
next sibling parent jmh530 <john.michael.hall gmail.com> writes:
On Tuesday, 14 June 2016 at 06:52:38 UTC, cym13 wrote:
 The web is a
 very dynamic place so I'd rather have a very dynamic language. 
 Maybe not
 javascript but really no D.
Isn't the idea of Typescript that there is a demand for static typing, or at least type annotations and compile-time type checking?
Jun 14 2016
prev sibling parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Tuesday, 14 June 2016 at 06:52:38 UTC, cym13 wrote:
 browser. It's
 main forces (compile-time stuff and speed) would have no impact 
 at all and
 the static typing would just make it harder for no good reason. 
 The web is a
 very dynamic place so I'd rather have a very dynamic language.
ah, that's why we have dart and typescript with static typing bolted on top of js... 'cause web needs more dynamics!
Jun 14 2016
parent reply Chris <wendlec tcd.ie> writes:
On Tuesday, 14 June 2016 at 12:49:03 UTC, ketmar wrote:
 On Tuesday, 14 June 2016 at 06:52:38 UTC, cym13 wrote:
 browser. It's
 main forces (compile-time stuff and speed) would have no 
 impact at all and
 the static typing would just make it harder for no good 
 reason. The web is a
 very dynamic place so I'd rather have a very dynamic language.
ah, that's why we have dart and typescript with static typing bolted on top of js... 'cause web needs more dynamics!
Dynamic typing should only be allowed to the extend `auto` works: var name = "Herbert" // ... name = "Brown" // ok name = 5 // error
Jun 14 2016
next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Tuesday, 14 June 2016 at 12:57:01 UTC, Chris wrote:
 Dynamic typing should only be allowed to the extend `auto` 
 works:

 var name = "Herbert"
 // ...
 name = "Brown"  // ok

 name = 5 // error
So var name = "Herbert"; name = "Brown"; name = 5; that will literally compiler in D today if you stick an "import arsd.jsvar;" in there too :) That's where my script.d came from - I wanted to see how closely I could simulate a "var" type in D itself, then got so close I decided to add a thin dynamic script around it too. But since the script and D both use the very same var type, the interop is easy.
Jun 14 2016
parent jmh530 <john.michael.hall gmail.com> writes:
On Tuesday, 14 June 2016 at 13:04:32 UTC, Adam D. Ruppe wrote:
 that will literally compiler in D today if you stick an "import 
 arsd.jsvar;" in there too :)
You can also do import std.variant; alias var = Variant; void main() { var name = "Herbert"; name = "Brown"; name = 5; }
Jun 14 2016
prev sibling parent ketmar <ketmar ketmar.no-ip.org> writes:
On Tuesday, 14 June 2016 at 12:57:01 UTC, Chris wrote:
 Dynamic typing should only be allowed to the extend `auto` 
 works:

 var name = "Herbert"
 // ...
 name = "Brown"  // ok

 name = 5 // error
this is still error-prone. why don't just do static typing instead, and introduce `anything` type, which is "variant", and can hold literally anything? with `auto` you'll barely need to think about types at all. and yep, compiler can turn runtime typechecks in compile-time specialization — kinda like templates. so we'll have something like this: // this does runtime type checks auto add (auto a, auto b) { return a+b; } // this does compile-time specialization, but // can also be executed by very straightforward // interpreter auto add2 (auto a, auto b) { if (typeof(a) is int && typeof(b) is int) { // here compiler knows actual types of `a` and `b` return a+b; } else { throw new Error("wut?!"); } }
Jun 14 2016
prev sibling parent reply Thomas Mader <thomas.mader gmail.com> writes:
On Tuesday, 14 June 2016 at 03:31:10 UTC, H. S. Teoh wrote:
 It's unlikely to happen in the near future, though, if at all. 
 But one can dream.  :-)
I think the big plan behind Web Assembly is to allow foreign languages an entry into the browser world. IIRC it's planned that the entire DOM will be accessible via Web Assembly at some point too. But thats quite far in the future. But with that I don't see any reason why D couldn't run directly in the browser and do the same stuff JavaScript does. Well except some technical details which are not clear to me now. :-D
Jun 14 2016
parent reply Chris <wendlec tcd.ie> writes:
On Tuesday, 14 June 2016 at 08:41:31 UTC, Thomas Mader wrote:
 On Tuesday, 14 June 2016 at 03:31:10 UTC, H. S. Teoh wrote:
 It's unlikely to happen in the near future, though, if at all. 
 But one can dream.  :-)
I think the big plan behind Web Assembly is to allow foreign languages an entry into the browser world. IIRC it's planned that the entire DOM will be accessible via Web Assembly at some point too. But thats quite far in the future. But with that I don't see any reason why D couldn't run directly in the browser and do the same stuff JavaScript does. Well except some technical details which are not clear to me now. :-D
Rather than pursuing JS endeavors, I was thinking of creating a light weight scripting language on top of D, something better than JS and not tied to the Web. Something people could use for day to day scripting tasks (like Python or Lua). Maybe we can build on the DMDScript engine, I don't know.
Jun 14 2016
next sibling parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Tuesday, 14 June 2016 at 09:30:02 UTC, Chris wrote:
 Rather than pursuing JS endeavors, I was thinking of creating a 
 light weight scripting language on top of D, something better 
 than JS and not tied to the Web. Something people could use for 
 day to day scripting tasks (like Python or Lua). Maybe we can 
 build on the DMDScript engine, I don't know.
you can start with "language report" (i.e. short semi-formal description of language). then people will have at least something to bikeshed. ;-)
Jun 14 2016
parent reply Chris <wendlec tcd.ie> writes:
On Tuesday, 14 June 2016 at 10:16:33 UTC, ketmar wrote:

 you can start with "language report" (i.e. short semi-formal 
 description of language). then people will have at least 
 something to bikeshed. ;-)
I'd say let's start with as few features as possible and concentrate on speed (including JIT) and extensibility. With extensibility I mean a) the language itself, i.e. it should be easy to extend the language without having to redesign the core and break everything, and b) easy integration of D and C. JS will become obsolete when other languages can be compiled to webasm, which is the right way to go. I wouldn't put too much effort into JS anymore.
Jun 14 2016
parent ketmar <ketmar ketmar.no-ip.org> writes:
On Tuesday, 14 June 2016 at 10:46:46 UTC, Chris wrote:
 I'd say let's start with as few features as possible
start with clean language design, or you will end up with javascript anyway. ;-)
Jun 14 2016
prev sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Tuesday, 14 June 2016 at 09:30:02 UTC, Chris wrote:
 Rather than pursuing JS endeavors, I was thinking of creating a 
 light weight scripting language on top of D, something better 
 than JS and not tied to the Web. Something people could use for 
 day to day scripting tasks (like Python or Lua). Maybe we can 
 build on the DMDScript engine, I don't know.
So, what I ideally want to do isn't actually a scripting language, but rather a really easy to use IPC and D build library. The end user thinks it is a script, it works the same way, they write a little program and load it up, but the application actually compiles it as D into an independent exe and spins it up as a new process, communication over a pipe and/or shared memory or something. The user script can then crash independently! And they can use the whole D language. The whole interface of interop can be automatically generated. Of course, the problem with the build thing is the program you write might need to be distributed with a D compiler.... though I don't think that's a dealbreaker, D compilers aren't that big and could be downloaded on demand by your program. (Well, dmd isn't, ldc/gdc is 10x bigger.)
Jun 14 2016
parent Chris <wendlec tcd.ie> writes:
On Tuesday, 14 June 2016 at 13:02:37 UTC, Adam D. Ruppe wrote:
 On Tuesday, 14 June 2016 at 09:30:02 UTC, Chris wrote:
 So, what I ideally want to do isn't actually a scripting 
 language, but rather a really easy to use IPC and D build 
 library.

 The end user thinks it is a script, it works the same way, they 
 write a little program and load it up, but the application 
 actually compiles it as D into an independent exe and spins it 
 up as a new process, communication over a pipe and/or shared 
 memory or something. The user script can then crash 
 independently! And they can use the whole D language. The whole 
 interface of interop can be automatically generated.

 Of course, the problem with the build thing is the program you 
 write might need to be distributed with a D compiler.... though 
 I don't think that's a dealbreaker, D compilers aren't that big 
 and could be downloaded on demand by your program. (Well, dmd 
 isn't, ldc/gdc is 10x bigger.)
Could we build on this: https://github.com/Hackerpilot/libdparse ?
Jun 17 2016
prev sibling parent yawniek <dlang srtnwz.com> writes:
On Tuesday, 14 June 2016 at 01:36:48 UTC, Yuxuan Shui wrote:
 On Tuesday, 14 June 2016 at 00:55:52 UTC, Walter Bright wrote:
 On 6/13/2016 5:13 PM, H. S. Teoh via Digitalmars-d wrote:
 My *real* dream is for D (or some suitable subset thereof) to 
 replace
 Javascript in browsers.  But that's a very distant, if at all 
 even
 possible, dream. :-D
It's a great dream!
Don't we have a pretty efficient JIT javascript implementation in D already? https://github.com/higgsjs/Higgs
higgs doesn't work if you want to zerocopy share data between D and the scripting language. so D here is more or less just the implementation language.
Jun 14 2016
prev sibling parent ketmar <ketmar ketmar.no-ip.org> writes:
On Monday, 13 June 2016 at 23:47:40 UTC, Walter Bright wrote:
 Remember you also have to write the documentation for your own 
 language, and write your own test suite. With Javascript you 
 can rely on existing documentation and test suites, which are 
 enormous time savers.
oh, noes. while tests *may* be time savers, ecmascript documentation is surely isn't. es is so full of quirks... sane scripting language can be documented in two pages of text. this may not allow to reimplement it 1:1, but will allow to use it without any troubles. did that IRL. and tests "grows organically", especially with dogfooding. it took me less than a month to make language usable. within next month or two i may be able to write it's own SSA codegen backend. more time here, as i forgot nearly everything i knew about SSA, and have to (re)learn some things. (not that i'll do that, it's just an estimation)
Jun 14 2016