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:


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:


 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)

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