import arsd.jsvar;
import std.stdio;

void main() {
  var a = 10;
  var b = a - 5;
  a = [1,2,3];
  a[1] = "two";
  writeln(a);

  a = json!q{
     "foo":{"bar":100},
     "joe":"joesph"
  };

  writeln(a.joe);
  a.bar += 55;
  b = a;
  writeln(b.bar);

  var c = (var d) { writeln("hello, ", d, "!"); };
  c("adr");
  c(100);

}


https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff/blob/master/jsvar.d


Ever since opDispatch came about, I've wondered just how close D can get to being like Javascript if we wanted to do that kind of thing. Last time I tried this, I hit bugs relating to opCall and constructors being mistaken for one another, but those dmd bugs have now been fixed.

So I tried again this weekend.... and there's the result. It works now! (Only problem left is the @property debacle, which is why I made yet another thread on that. But meh, that isn't even a big deal.)


The var type is, as you can see, both weakly and dynamically typed. Now, I know weak and dynamic typing sucks. But the beauty with D is you can use whatever you want. std.variant offers strong, dynamic typing. D itself offers strong, static typing. And now var offers the weak/dynamic quadrant.

Why would you use this? idk, maybe json, maybe script interaction (see below), but I did it more because I can than any real goal.


I just think D rox that it can do all this under one language.



But, if we can do this in D, wouldn't it be nice to interop with a scripting language so easily too? I thought so, so Sunday and some more today, I slapped together a quick script interpreter that uses this var type:

https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff/blob/master/script.d



auto globals = var.emptyObject;
// these global variables will be available to the script
globals.lol = 100;
globals.rofl = 23;

// and functions too
globals.write = (var a) { writeln("script said: ", a); };

// read from file
import std.file;

// this can contain: var c = function(a) { write(a); };
writeln(interpret(readText("scripttest_code.d"), globals));

// or from stdin
repl(globals);

writeln("BACK IN D!");
globals.c()(10); // call script defined functions in D




(I thought about tying into dmdscript, but meh, doing my own language let me use the var type without wrapping it, and I could play with some other ideas too. I think the idea of using mixins to forward script operators to D is potentially very interesting - perhaps I could add static typing to the script that depends on dmd to do the actual work. But for now all it offers is the var type.)


That script language isn't quite complete, I just quickly hacked it together to play with. Notably, "return" doesn't actually work. But most of the functions and for loop and math stuff do, as well as some nice imports from D like exceptions and scope guards.


What's most interesting isn't the script itself though, it is how easy it can be to integrate it with the rest of a D program, like shown above.



Is any of this useful for anything? idk, maybe parsing json or maybe the script language could find use. But the real point I'm trying to make here is simply that...

d rox.

On Fri, Jul 5, 2013 at 5:21 AM, Adam D. Ruppe <destructionator@gmail.com>wrote:

> [snip]

d rox.
>

!!! this is AWESOME!

Now one can use a mix of static and dynamic typing which is really nice
with document based databases.
Being able to script subsections of a website is also really interesting.
Nice bridge for javascript programmers to learn to use D.
Just need a decent wrapper on phobos to fix the naming of some stuff.

There are many cases where you do not know in advance what type of data is being received through an interface to some other system. This happens with some databases, and with messaging systems, and if you are interfacing to any dynamically or weakly typed language, such as with js/json.

I will be looking at what you did closely, so thanks for sharing! I'll also look at the interpreter, many uses for something like that too.

Originally to solve these interfacing problems, I wrote a property tree implementation in C++ that used a dynamically typed variant similar to your "var" type. With a property tree, you can dynamically generate any hierarchical structure to multiple and varying depths, great to have when you have no idea what the structures will look like in advance.

For the variant type, I added in protection for strong typing, but it could be by-passed with automatic conversion (if possible) between types. I used it to create a generalized API for sqlite databases. Later on it was used for interfacing with messages recvd/sent via json over tcp.

Later after deciding to switch to D, the first thing I did was to re-write a similar property tree system in D, and the experience was much better although with one notable exception: Unlike in C++,  I could not create conversion operators that infer the receiving type when doing assignments from the variant, for example:

int i;
char c;
i = var;
c = var;

in C++ the correct "getter" for returning int or char will be called
eg

operator int(){...}
operator char(){...}

In D, I have to resort to something a manual system like this:

i = var.get!int;
c = var.get!char;

Not nearly as nice.

I suppose i could to this
c = var.get!(typeof(c));

Safer but very ugly and tedious.

My hope is if multiple alias ever arrives it will solve the conversion issue. Do you have any insight on how to solve the conversion problem using current D, and if you think multiple alias this will solve the problem?

--rt

On Friday, 5 July 2013 at 22:51:57 UTC, Rob T wrote:
> I suppose i could to this
> c = var.get!(typeof(c));

Yeah, I did two things: int c = var.get!int; and

int c;
var v;
v.putInto(c);

> [do] you think multiple alias this will solve the problem?

Maybe, but that would still be limited to a list of types. What would be ideal is if alias this or opImplicitCast existed, or implicit constructors like C++ has for function calls.... and could be a template:

T get(T)() { ...}

alias get this;

int a = v; // rewrites to v.get!(int)


That won't work in all cases, there will be some where the type requested is uncertain or ambiguous, but I'd say just go ahead and error out there or pass the original var, if possible, because this should cover most assignments.



But overall, I don't think the get!int is too bad. It is kinda nice to know where you are transitioning back into static typed world anyway.



BTW I'll push another commit to jsvar.d and script.d over the weekend. I got return/break/continue working now (in the cases I've tried at least, simple ones).

On 7/5/13 4:04 PM, Adam D. Ruppe wrote:
> BTW I'll push another commit to jsvar.d and script.d over the weekend. I
> got return/break/continue working now (in the cases I've tried at least,
> simple ones).

I think you really should put the code in shape and convert your initial post into a blog entry. For a blog post at the level "hmm, interesting" I think you're already good to go. (An article would need more polishing.)

I'd be glad to post it to reddit on Monday morning. Let me know.


Andrei

On Friday, 5 July 2013 at 03:21:31 UTC, Adam D. Ruppe wrote:
> Is any of this useful for anything? idk, maybe parsing json or maybe the script language could find use. But the real point I'm trying to make here is simply that...
>
> d rox.

Awesome work, and I think it's a nice code to study more about D too.

PS: I just think that "var" is "maybe" too generic, I would called it as jsvar or anything like that, but this is just my opinion, anyway I liked your solution.

Matheus.

On Friday, 5 July 2013 at 23:04:28 UTC, Adam D. Ruppe wrote:
> Maybe, but that would still be limited to a list of types. What would be ideal is if alias this or opImplicitCast existed, or implicit constructors like C++ has for function calls.... and could be a template:
>
> T get(T)() { ...}
>
> alias get this;
>
> int a = v; // rewrites to v.get!(int)
>

Yes that would be much better.

What I always wanted to see, was full signature overloading rather than only the partial signature overloading we currently have.

eg

int get();
char get();

int a = get(); // calls int foo()
char b = get(); // calls char foo()

Technically there's no reason why this won't work. The cases where there's ambiguity are virtually identical to what we already experience with partial signature overloading. I have no idea why this has not been seen as useful in most other languages, it seems like a natural extension of the overloading concept. I think only Haskel does something like it.

--rt

On Friday, 5 July 2013 at 08:26:23 UTC, Rory McGuire wrote:
> Just need a decent wrapper on phobos to fix the naming of some stuff.

That's fairly easy too:

import arsd.jsvar;
import arsd.script;

void main() {
        var globals = var.emptyObject;
        {
              import std.algorithm;
              var Math = globals.Math = var.emptyObject;
              Math.max = &std.algorithm.max!(var, var);


                // testing it in D
                import std.stdio;
                 // the second () is just because @property is broken
                writeln(Math.max()("12", 24)); // prints 24

        }
        {
              import std.file;
              var File = globals.File = var.emptyObject;
              File.readText = &readText!string;
        }

        import std.stdio;
        writeln(interpret("Math.max(14, 33);", globals)); // prints 33
        writeln(interpret("File.readText(\"test29.d\");", globals)); // prints this file's source code
}


The opAssign function can wrap native functions pretty much automatically. The one thing, as you can see here, is they do need to be functions, not templates, so you might have to instantiate them all with some type. But that's no big deal.

I don't remember if I mentioned this or not too, but the opAssign and .get!T functions also can go to and from structs. Only the data members, the methods won't work since the this pointer for them would point to a var instead of the real type it expects, but the data members and pulled/filled in by name, coercing types as needed.


Anyway, if you did all these assignments, then you can make it all available with dynamic calling from D or from the script interpreter, without manually wrapping them.


It shouldn't be too hard to do a __traits(allMembers) over a module too if you wanted to pull it all in at once, perhaps even automatically instantiating the templates. But it would only work especially well for free functions, again, due to the delegate this problem. (Which I have an idea on how to solve - keep a copy of the real type around, and update its pieces by way of a proxy function that takes the name and searches for it, so the delegate this/context pointer is still sane, but it was kinda buggy so I dropped it. Another option would be to have other type tags available, not just generic Type.Object, but something like Type.NativeObject too that is added to the union. But meh, this is pretty cool as it is imo.)

On Friday, 5 July 2013 at 23:51:16 UTC, MattCoder wrote:
> PS: I just think that "var" is "maybe" too generic, I would called it as jsvar or anything like that, but this is just my opinion, anyway I liked your solution.

I just wanted the authentic javascript experience :P

You could also rename it with a selective import or something too.

On Friday, 5 July 2013 at 23:58:30 UTC, Rob T wrote:
> What I always wanted to see, was full signature overloading rather than only the partial signature overloading we currently have.

Indeed, that would be pretty cool.