JassHelper 0.A.2.B - A vJass and Zinc 2 Jass compiler

[Vexorian]

That might actually be useful. It would be good because it'd allow ifs inside of static ifs

Ifs inside static ifs are already possible.

weaaddar: I'd love type inference and have always wished to have that in vjass/zinc, hope I ever get to write the better compiler I've been planning for so long.

[Rising_Dusk]

Oh you fixed that? Cool. What about my edit?

[Vexorian]

I never fixed that, it has always been possible to use ifs inside static ifs and vice versa.

You mean converting function ... to function interface when used in one of such arguments? I am slowly adding type safety and it will happen, really (mostly because it will allow my zinc anonymous functions to be abused in very nice ways...)

[Rising_Dusk]

Originally Posted by Vexorian

I never fixed that, it has always been possible to use ifs inside static ifs and vice versa.

Could've sworn some people reported weird bugs with it. Oh well, thanks either way.

[Vexorian]

0.A.2.7

[Rising_Dusk]

I need to do this:

JASS:

private function HookDestroyBoolExpr takes boolexpr b returns nothing
    local integer bid = GetHandleId(b)
    if HaveSavedHandle(H, 0, bid) then
        //Clear the saved boolexpr
        call DestroyBoolExpr(LoadBooleanExprHandle(H, 0, bid))
        call RemoveSavedHandle(H, 0, bid)
    endif
endfunction

hook DestroyBoolExpr HookDestroyBoolExpr

But it will hook the other DestroyBoolExpr inside the hook function, resulting in an unwanted extra call of the function (It will not destroy the boolexpr the second time, so no infinite loop, but it does call it the function twice for no good reason). Is there any way you can add some way for us to 'disable a hook' temporarily if called inside a hook function callback?

There are workarounds, but all of them result in the hook function being called twice instead of once.

[Bobo_The_Kodo]

JASS:

private function HookDestroyBoolExpr takes boolexpr b returns nothing
    local integer bid = GetHandleId(b)
    if HaveSavedHandle(H, 0, bid) then
        //Clear the saved boolexpr
//! novjass
        call DestroyBoolExpr(LoadBooleanExprHandle(H, 0, bid))
//! endnovjass
        call RemoveSavedHandle(H, 0, bid)
    endif
endfunction

hook DestroyBoolExpr HookDestroyBoolExpr

would that not work?

[Vexorian]

novjass actually behaves like the <noscript> tag.

[weaaddar]

Vex, annonymous functions still don't seem to like me much::

This throws compile errors on type even after usng the latest jasshelper,

Zinc:

//! zinc
library anony
{
    hashtable context = InitHashtable();
    type func_int_int extends function(integer)->integer;
    type Ucombinator extends function(Ucombinator)->func_int_int;

    function test()
    {
        Ucombinator U = function(Ucombinator f)->func_int_int
        {
            return f.evaluate(f);
        }
        func_int_int factorial = U.evaluate(function(Ucombinator f)->func_int_int
        {
            SaveInteger(context,0,0,integer(f));
            return function(integer n)->integer
            {
                func_int_int f = LoadInteger(context,0,0);
                FlushChildHashtable(context,0);
                if(n == 0) return 1;
                return (f.evaluate(f)).evaluate(n-1);
            }
        });
        call BJDebugMsg(I2S(factorial.evaluate(5)));
    }
}
//! endzinc

But holy crap you implemented +=? isn't that just as bad as ++?

[Earth-Fury]

Originally Posted by weaaddar

But holy crap you implemented +=? isn't that just as bad as ++?

+= is limited to assignment statements. ++ can be used in any expression. So, no, not really.

[weaaddar]

You know c# tends to think you're wrong sonny::
int xx = 0;
int jj = 0;
xx = jj += 5;

[Vexorian]

I figured limiting to statements prevents giving the coders false expectations while allowing more expressive syntax.

I would add ++ as well, but when limiting it to statements, it really makes no sense not to just let it be +=1...

Code:

You know c# tends to think you're wrong sonny::

Most C-like languages allow these as expressions. But in this case, I am going python-ish with it. It is saner considering this way I don't have to deal with compiling that stuff to Jass...

[weaaddar]

So any idea why that code above gives me this compile error;
Line 19: Unexpected "func_int_int"?
func_int_int factorial = U.evaluate(function(Ucombinator f)->func_int_int

[Vexorian]

this works:

Zinc:

library anony
{
    hashtable context = InitHashtable();
    type func_int_int extends function(integer)->integer;
    type Ucombinator extends function(Ucombinator)->func_int_int;

    function test()
    {
        Ucombinator U = function(Ucombinator f)->func_int_int
        {
            return f.evaluate(f);
        };
        func_int_int factorial = U.evaluate(function(Ucombinator f)->func_int_int
        {
            SaveInteger(context,0,0,integer(f));
            return function(integer n)->integer
            {
                func_int_int f = LoadInteger(context,0,0);
                FlushChildHashtable(context,0);
                if(n == 0) return 1;
                return f.evaluate(f).evaluate(n-1);
            };
        });
        BJDebugMsg(I2S(factorial.evaluate(5)));
    }
    
    function onInit()
    {
        test();
    }
}

I added some semicolons after some anonymous functions, I also removed parenthesis on return f.evaluate(f).evaluate(n-1); our beloved compiler sucks like that - it has Alzheimer and will forget the type of something if you use parenthesis, hope next time I update I remember to fix this issue...

[weaaddar]

Well, that is a funny bug. However, with some horrible pain I implemented the YCombinator in lambda expressions. Since type arguments are really ugly I kind of got lazy and just gave it a nice short name, but suffice to say the type of Y should be ugly.

Anyway, lol anonymous recursion in Zinc!

Zinc:

library anony
{
    hashtable context = InitHashtable();
    type func_int_int extends function(integer)->integer;
    type Ucombinator extends function(Ucombinator)->func_int_int;
    type Yarg extends function(func_int_int)->func_int_int;
    type Ycombinator extends function(Yarg)->func_int_int;
    
    function U(Ucombinator f)->func_int_int
    {
        return f.evaluate(f);
    }
    function test()
    {
        
        //return U(r => a => f(r(r))(a));
        Ycombinator Y = function(Yarg f)-> func_int_int
        {
            SaveInteger(context,1,0,integer(f));
            return U(function(Ucombinator r)-> func_int_int
            {
                SaveInteger(context,1,1,integer(r));
                return function(integer a)->integer
                {
                    Yarg f =LoadInteger(context,1,0);
                    Ucombinator r = LoadInteger(context,1,1);
                    return f.evaluate(U(r)).evaluate(a);
                };
            });
        };
        
        
        
        func_int_int factorial = Y.evaluate(function(Yarg f)->func_int_int
        {
            SaveInteger(context,0,0,integer(f));
            return function(integer n)->integer
            {
                func_int_int f = LoadInteger(context,0,0);
                if(n == 0) return 1;
                return n*f.evaluate(n-1);
            };
        });
        BJDebugMsg(I2S(factorial.evaluate(5)));
    }
    
    function onInit()
    {
        test();
    }
}

I made U its own function to make life easier. I suppose I could've not. And really written it out the hardcore way.

Once again, I'm completely amazed at what you've accomplished Vexorian. I've never thought I'd actually be able to write lambda expressions even if they have horrible C++0x style syntax in Jass!