On Friday, 16 March 2012 at 09:12:57 UTC, F i L wrote:
> Alright I give up dammit! How do you use opCall() to make a.cool() work?

How would it be possible, the type of the delegate can't be typechecked at the call-site, because the type info is lost in the variant. And you can't exhaustively test for all function types in the opDispatch getter.
opDispatch would have to store the names and types internally at compile-time, which isn't possible. But even then it would have to be guaranteed that all setter calls are evaluated before the getter calls are checked.
Maybe one could manually store the type info in a special struct together with the delegate and then cast it to that type in the opDispatch getter.

On Friday, 16 March 2012 at 09:12:57 UTC, F i L wrote:
> Alright I give up dammit! How do you use opCall() to make a.cool() work?

I was a little unclear... but you'll have to modify
std.variant and/or wrap it.

Here's a solution that wraps it:

==

import std.traits;
import std.variant;

// we want to give a common interface to all functions,
// which is what this wrapper tries to do.

// note it is kinda buggy; this is just a quick example,
// not a finished product
Variant delegate(Variant[]) wrap(alias t)() {
  return delegate Variant(Variant[] args) {
    ParameterTypeTuple!(typeof(t)) ptt;
    foreach(i, param; ptt) {
      if(i == args.length)
        break; // or throw if you want strictness
      // BTW, you can do default params and names too,
      // but it takes a fair amount of code. Check
      // out my web.d generateWrapper() for this if
      // you are interested.

          // or get for strictness
      ptt[i] = args[i].coerce!(typeof(param));
    }

    Variant returned;
    static if(is(ReturnType!(typeof(t)) == void))
      t(ptt);
    else
      returned = t(ptt);

    return returned;
  };
}

// here's our variant wrapper...
struct MyVariant {
  Variant delegate(Variant[]) callable;
  Variant value;

  alias value this;

  // the main trick here is when we construct or assign,
  // we have compile time info about the function. So, we
  // use this opportunity to build a delegate to call it dynamically.
  this(T)(T t) {
    value = t;
    static if(isCallable!T) {
      callable = wrap!(t)();
    } else {
      callable = null;
    }
  }

  // and here, we use the delegate made above
  Variant opCall(T...)(T t) {
    if(!callable)
      throw new Exception("not callable");
    Variant[] args;
    foreach(i, v; t)
      args ~= Variant(v);
    return callable(args);
  }

  MyVariant opAssign(T)(T t) {
    // FIXME: copy/paste from constructor because otherwise it
    // tries to call a simple delegate instead of passing the delegate itself..
    value = t;
    static if(isCallable!T) {
      callable = wrap!(t)();
    } else {
      callable = null;
    }
    return this;
  }
}


// let's test it
import std.stdio;

void main () {
  MyVariant v = 10;
  //v(); // would throw

  v = { writefln("Hello, world!"); };
  v(); // says hello!
}
==




One of the big bugs is that the compile conflates
instance opCall, static opCall, and constructors in
such a way that it sometimes calls the wrong one.

This makes calling things with parameters a pain
in the ass, and I hope dmd eventually fixes this.


For instance, add this to the end:


        v = function(int a) { writeln("whoa: ", a); };
        v(10);



And the stupid compiler thinks v(10) is calling the
struct's constructor again.

Why would you /ever/ want that on an instance?


It also complains if you declare opCall and static opCall
separately. Why?



You can work around this by making MyVariant a class. No
constructor (that apparently doesn't work right either. This
is bug city!), just opAssign.

Then you can do:
==
        auto v = new MyVariant();

        v = { writefln("Hello, world!"); };
        v(); // says hello

        v = function(int a) { writeln("whoa: ", a); };
        v(10); // says whoa: 10


        // look, a std.variant bug too while we're at it
        // fix this in std.variant tho, and it will work too
        // v("12"); //  Type immutable(char)[] does not convert to int
==


This isn't something I use every day, but even in bug city,
it isn't /too/ hard to make it work in D, including weak
typing and variable argument lists, just like Javascript if
we want to. Or, we can go tougher with minor changes.


D rox despite bugs.

On 16/03/2012 02:28, Nick Sabalausky wrote:
> "James Miller"<james@aatch.net>  wrote in message
> news:mailman.733.1331853568.4860.digitalmars-d@puremagic.com...
>>
>> I hate the fact that Flash games are created the way they are. For
>> one, it's impenetrable to try and learn properly, I had so much
>> trouble figuring out how to do things properly, you can attach scripts
>> to almost any object, but sometimes it might be shared over all of the
>> same objects, and other times only on that instance, depending on how
>> you've placed them on the canvas.
>>
>> I probably wrote some terrible code when I started making Flash games,
>> and now Actionscript is so foreign to me that i can barely understand
>> where to start.
>>

> One thing I learned though, is that if you're going to make something in
> Flash, your best bet is to use as *little* of what Adobe provides as
> possible:

You're being rather unfair to Adobe. It was Macromedia that where the original perpetrators of flash; Adobe brought Macromedia in 2005.
I guessing that they only brought Macromedia for the market share rather than because they thought flash was actually any good.

I suffered through a module of Flash/Director around 1999. Action script was fecking awful but Director actually wasn't that bad.
It was pretty easy to do some neat things so it was easy to see why it was so popular with *web devs* and mouth breathing marketing types.

-- 
My enormous talent is exceeded only by my outrageous laziness.
http://www.ssTk.co.uk

"Simon" <s.d.hammett@gmail.com> wrote in message news:jk053b$sg0$1@digitalmars.com...
> On 16/03/2012 02:28, Nick Sabalausky wrote:
>> "James Miller"<james@aatch.net>  wrote in message news:mailman.733.1331853568.4860.digitalmars-d@puremagic.com...
>>>
>>> I hate the fact that Flash games are created the way they are. For one, it's impenetrable to try and learn properly, I had so much trouble figuring out how to do things properly, you can attach scripts to almost any object, but sometimes it might be shared over all of the same objects, and other times only on that instance, depending on how you've placed them on the canvas.
>>>
>>> I probably wrote some terrible code when I started making Flash games, and now Actionscript is so foreign to me that i can barely understand where to start.
>>>
>
>> One thing I learned though, is that if you're going to make something in Flash, your best bet is to use as *little* of what Adobe provides as possible:
>
> You're being rather unfair to Adobe. It was Macromedia that where the
> original perpetrators of flash; Adobe brought Macromedia in 2005.
> I guessing that they only brought Macromedia for the market share rather
> than because they thought flash was actually any good.
>
> I suffered through a module of Flash/Director around 1999. Action script
> was fecking awful but Director actually wasn't that bad.
> It was pretty easy to do some neat things so it was easy to see why it was
> so popular with *web devs* and mouth breathing marketing types.
>

Well, yea Macromedia created most of it, but Adobe now *provides* it ;) And they did choose to buy it. Anyway though, yea, you're right it is mostly Macromedia. Actually the version I started using was still pre-Adobe: MX 2004. But still, it's been about 6 years and Adobe, well they promtly added AS3 (which like I said, I admit I don't know much about since I haven't used it) and then ever since then they seem to have mostly just added bloat. Again though, you're right, Macromedia's responsible for most of what I hate about Flash (Apperently even Flex is their fault, too. I didn't even know that until I looked it up just now).

On Friday, 16 March 2012 at 14:23:20 UTC, Adam D. Ruppe wrote:
> On Friday, 16 March 2012 at 09:12:57 UTC, F i L wrote:
>> Alright I give up dammit! How do you use opCall() to make a.cool() work?
>
> I was a little unclear... but you'll have to modify
> std.variant and/or wrap it.
>
> Here's a solution that wraps it:
> [snip]

Thank you for all the code. :)


> D rox despite bugs.

Yes it does. I'm sure it wont be too long before all this stuff is fixed up a bit.

On Friday, 16 March 2012 at 22:48:44 UTC, F i L wrote:
> Yes it does. I'm sure it wont be too long before all this stuff is fixed up a bit.

Aye. I just sent a pull request for the minor std.variant
thing (so strings can be converted to ints - we can do
weak typing more easily now if we want).

The opCall stuff is probably a lot harder to fix. Much
of it is legacy from D1 I think.


But it is pretty usable today, anyway. Use the class
and assignment operator and it works well.

The biggest annoyance is that @property doesn't work
right (not even with -property). So, if you merge
this with the opDispatch code from an earlier post,
you can do:


a.myProperty = { writeln("hello!"); }

a.myProperty(); // does nothing because it thinks you are doing the getter...

a.myProperty()(); // this work. first paren does get, second does call.

On Friday, 16 March 2012 at 11:22:07 UTC, Boscop wrote:
> How would it be possible, the type of the delegate can't be typechecked at the call-site, because the type info is lost in the variant.

The trick is to build wrapper functions at the assignment
point, where you still have all the type info.

I showed that with the wrap() template in the implementation
in a previous post - std.traits.ReturnType and
std.traits.ParameterTypeTuple help a lot there.

This same technique can do all kinds of conversions: I
use it to do strings -> calls for web apps and Variant ->
calls for this dynamic thing, weak typing, and script
interaction.

Remember, that while the wrapper is showed at the
assignment type, it is a compile time thing to
build the wrapper, so the assignment is still cheap.

The call has a small runtime hit though, since it does
the type conversions or checks there.

If you wanted strict type checking, it could probably
be fast; Variant.get() has a small cost.

so:

> Not related to D but this is a community which i can find at least a few objective person. I want to invest some "quality" time on a dynamic language but i am not sure which one. Would you please suggest one?
> 
> To give you an idea what i am after:
> Of all one-liners i have heard only one gets me.
> "The programmable programming language". Is it true? If so Lisp
> will be my first choice.

There are several dynamic languages available, and different ones are better for different purposes.

The general purpose dynamic language that I suggest is Python, because it's very readable, it's very handy to write prototypes in, it allows a low bug count, it's widespread and you can find all kind of libs for it.

Lua is better for interfacing with C, and the small size makes it good to write the logic for games, and its JIT is the best.

Clojure seems nice for low-performance parallel code. It's a bug un-prone language.

Qi and its derivatives have the most powerful type system.

Bye,
bearophile

I mostly do game scripting -- and there are quite a few features in D that I would like access to.

Python would be my goto dynamic language mostly because a lot of the applications I use are either partially written in it or can be scripted easily using it. Also it is quite an enjoyable language to use when performance isn't your primary concern. It escapes back to C quite efficiently though which I think is one of the main reasons it is so widely used.

I also like Perl (though I haven't actually needed to use it for many years now) for it's expressiveness.

The other dynamic language I would concider quite useful is javascript and not just for web.

That being said I generally choose the task first and the language second. D is perhaps the second time I have learned a language for the fun of it.

On Fri, Mar 16, 2012 at 5:15 AM, Manu <turkeyman@gmail.com> wrote:

> On 15 March 2012 20:59, so <so@so.so> wrote:
>
>> Thank you all!
>>
>>
>> On Thursday, 15 March 2012 at 17:30:49 UTC, Adam D. Ruppe wrote:
>>
>>> On Thursday, 15 March 2012 at 07:09:39 UTC, so wrote:
>>>
>>>> If so Lisp will be my first choice.
>>>>
>>>
>>> I just talked about D because D rox, but if you are doing it for education, Lisp is a good choice because it is fairly unique.
>>>
>>
>> I'd love to use D but it is not an option is it? At least for the things i am after, say game scripting.
>
>
> I dunno, that sounds like a pretty interesting idea to me! :)
>