June 10, 2016 Re: Andrei's list of barriers to D adoption | ||||
---|---|---|---|---|
| ||||
Posted in reply to Chris | On Friday, 10 June 2016 at 10:03:29 UTC, Chris wrote: > A scripting language based on D? Is it open source? I've always dreamt of something like that. i have several of them, actually. yet they are very specialized — i.e. designed to support my game engines, not to be "wide-area scripting languages". publicly accessible are: DACS[1] — statically typed, with modules and UFCS, and JIT compiler built with LibJIT[2], optionally supports internal stack-based VM. GML[3] — part of my WIP Game Maker 8 emulator, register-based 3-op VM, no JIT. [1] http://repo.or.cz/dacs.git [2] https://www.gnu.org/software/libjit/ [3] http://repo.or.cz/gaemu.git |
June 10, 2016 Re: Andrei's list of barriers to D adoption | ||||
---|---|---|---|---|
| ||||
Posted in reply to ketmar | On Friday, 10 June 2016 at 10:21:07 UTC, ketmar wrote:
>
> i have several of them, actually. yet they are very specialized — i.e. designed to support my game engines, not to be "wide-area scripting languages".
>
> publicly accessible are:
>
> DACS[1] — statically typed, with modules and UFCS, and JIT compiler built with LibJIT[2], optionally supports internal stack-based VM.
>
> GML[3] — part of my WIP Game Maker 8 emulator, register-based 3-op VM, no JIT.
>
>
> [1] http://repo.or.cz/dacs.git
> [2] https://www.gnu.org/software/libjit/
> [3] http://repo.or.cz/gaemu.git
Cool. I'd love to see `DScript` one day - and replace JS once and for all ... well ... just day dreaming ...
|
June 10, 2016 Re: Andrei's list of barriers to D adoption | ||||
---|---|---|---|---|
| ||||
Posted in reply to Chris | On Friday, 10 June 2016 at 10:55:42 UTC, Chris wrote: > Cool. I'd love to see `DScript` one day - and replace JS once and for all ... well ... just day dreaming ... Adam has scripting engine in his arsd repo[1]. it's not a speed demon, but it is much more like JS, it even has exceptions, and it is very easy to integrate it with D code. you may take a look at it too. afair, you only need jsvar.d and script.d modules to use it. [1] https://github.com/adamdruppe/arsd |
June 10, 2016 Re: Andrei's list of barriers to D adoption | ||||
---|---|---|---|---|
| ||||
Posted in reply to ketmar | On Friday, 10 June 2016 at 11:05:27 UTC, ketmar wrote:
> Adam has scripting engine in his arsd repo[1]. it's not a speed demon, but it is much more like JS, it even has exceptions, and it is very easy to integrate it with D code. you may take a look at it too. afair, you only need jsvar.d and script.d modules to use it.
>
> [1] https://github.com/adamdruppe/arsd
Nice. Anyone interested in turning this into "DScript"? Having a scripting language powered by D would also boost D's prestige. And it would be easy to write modules in pure D.
DScript could then be used by scientists, game developers etc. à la Python and if speed is crucial, just write a module in pure D.
|
June 10, 2016 Re: Andrei's list of barriers to D adoption | ||||
---|---|---|---|---|
| ||||
Posted in reply to Chris | On Friday, 10 June 2016 at 11:11:49 UTC, Chris wrote:
> Nice. Anyone interested in turning this into "DScript"? Having a scripting language powered by D would also boost D's prestige. And it would be easy to write modules in pure D.
>
> DScript could then be used by scientists, game developers etc. à la Python and if speed is crucial, just write a module in pure D.
it looks like you just described a project you can start yourself! ;-)
|
June 10, 2016 Re: Andrei's list of barriers to D adoption | ||||
---|---|---|---|---|
| ||||
Posted in reply to ketmar Attachments:
| On Tue, 2016-06-07 at 11:21 +0000, ketmar via Digitalmars-d wrote: > On Tuesday, 7 June 2016 at 11:11:31 UTC, Russel Winder wrote: > > On Tue, 2016-06-07 at 09:55 +0000, ketmar via Digitalmars-d wrote: > > > > > […] > > > considering that the whole package, including dlangUI, is one man work... give it a chance! ;-) > > > > A project starting as a one person thing is quite natural, a project aiming to gain traction remaining a one person project is a dead end siding. > > not everybody is good at promoting their work. yes, this skill is required to make your project wide-known (and then wide-used), but... this is where other people can step in to help. i'm sux in promoting things too, so i'm doing as much as i can: mentioning the project occasionally here and there. My point was not so much a direct marketing one more an indirect one: if a project is claiming to be a production thing usable by all and sundry but is a one-person project, then it isn't actually production ready. It may actually be production ready, but it will not be perceived as that: person under a bus scenario and all that. -- Russel. ============================================================================= Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder@ekiga.net 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder |
June 10, 2016 Re: Andrei's list of barriers to D adoption | ||||
---|---|---|---|---|
| ||||
Posted in reply to ketmar | On Friday, 10 June 2016 at 11:20:35 UTC, ketmar wrote:
> On Friday, 10 June 2016 at 11:11:49 UTC, Chris wrote:
>> Nice. Anyone interested in turning this into "DScript"? Having a scripting language powered by D would also boost D's prestige. And it would be easy to write modules in pure D.
>>
>> DScript could then be used by scientists, game developers etc. à la Python and if speed is crucial, just write a module in pure D.
>
> it looks like you just described a project you can start yourself! ;-)
I have neither time nor the required expertise to write a scripting language from scratch ;) You on the other hand ... :-)
|
June 10, 2016 Re: Andrei's list of barriers to D adoption | ||||
---|---|---|---|---|
| ||||
Posted in reply to Yura | On Friday, 10 June 2016 at 08:29:50 UTC, Yura wrote: > Another things where I do almost all my mistakes is: array bounding/calling the memory which was free => the result is undefined behavior. If I remember correctly the D is better with that respect? I think slices and automatic bound checking is the most important improvement of D over C. An important concern in simulations (mentioned by one using D in bioinformatics) is correctness: if you have a bug, the program is not guaranteed to crash, it can just give an incorrect result. > Anyway, super easy way to use all C libraries + super active support would clearly help to increase D popularity/adoption. All other point I raised are perhaps not that important. I'm not as optimistic about binding C libraries as others :) I think it requires skills. |
June 10, 2016 Re: Andrei's list of barriers to D adoption | ||||
---|---|---|---|---|
| ||||
Posted in reply to Chris | On Friday, 10 June 2016 at 13:55:28 UTC, Chris wrote:
> I have neither time nor the required expertise to write a scripting language from scratch ;) You on the other hand ... :-)
so just use Adam's code as the starting point then! ;-)
|
June 10, 2016 Re: Andrei's list of barriers to D adoption | ||||
---|---|---|---|---|
| ||||
Posted in reply to Chris | On Friday, 10 June 2016 at 13:55:28 UTC, Chris wrote: > I have neither time nor the required expertise to write a scripting language from scratch ;) You on the other hand ... :-) Oh, it isn't that hard, at least to do a quick basic thing. You might want to start with the various math parsers. A postfix one is relatively easy: 2 3 + break it up into tokens, read them in, build a syntax tree (well, for the postfix thing, it is probably a stack!). That approach will even work for a Lisp-like language! Then try an infix one. You'd use the same tokenizer, but the parser is different... and this kind of parser gets you started for a typical script language. 2 + 3 The way this works is you read the token, peek ahead, create an object and build a tree. You'd use different functions for different contexts. So it might start with readExpression which readFactor. Then readFactor might call readAddend... If you look at the D grammar: http://dlang.org/spec/grammar.html you'll find the various terms are defined as WhateverExpressions and often recursively... you can write the parser to follow that basically the same way! You end up with one of these: https://en.wikipedia.org/wiki/Recursive_descent_parser Once you get addition and multiplication working with correct order of operations, you just kinda start adding stuff! Make a function call and an if/loop statement and boom, you have a simple programming language. After that, it is basically just adding more token recognition and AST classes. To make an interpreter, you can just add a method to the AST objects that interprets and gives a result.... boom, it works! Compiling is basically the same idea, just spitting out something other than the result of the expression - spitting out code that gives you the result. That gets harder to get into all the fancy techniques, but it builds on the same foundation. It is a good thing to know how to do, at least the basic parts! |
Copyright © 1999-2021 by the D Language Foundation