Discussion New Language - Discussion

[ertaboy356b]

> 3. Built-in Libraries?

The compiler will have built-in libraries such as TimerUtils so we don't have to download it.. We can just call them whenever we want.. The parser will automatically add the libraries whenever a function from that library is called..

> 4. Overloading

function MyFunc takes integer a, [integer b=3] returns integer
    return a + b
endfunction

We can call this as:

call MyFunc(3)

which will return an integer 3 + 3 = 6

or call it like

call MyFunc(5,6)

which will return an integer 5 + 6 = 11

 

[Lyerae]

> 3. Built-in Libraries?

The compiler will have built-in libraries such as TimerUtils so we don't have to download it.. We can just call them whenever we want.. The parser will automatically add the libraries whenever a function from that library is called..

Okay, that makes sense.
They won't be built in, but they will come packaged.

> 4. Overloading

function MyFunc takes integer a, [integer b=3] returns integer
    return a + b
endfunction

We can call this as:

call MyFunc(3)

which will return an integer 3 + 3 = 6

or call it like

call MyFunc(5,6)

which will return an integer 5 + 6 = 11

I don't see the point.

 

[Vexorian]

I called this Ycry. You can't read Ycry. It was a hypothetical JASS extending language which aimed purely at development speed, at the sacrifice of all else. Ironically, after writing the language, I decided how much I loved the readability of vJASS.

Focusing on typing speed will always mean failure. Programmers spend more time reading their own code when developing than typing it.

Just wanted to say: DON'T USE FREAKING # FOR PREPROCESSOR DIRECTIVES.

There are reasons for //! . Good reasons. At first I was going to use # but it was back when Karukef had wewarlock and he was already using //! , seemed silly to me, but after a long chat with Karukef and Pipedream I finally understood it... Short story : It seriously saved me a lot of annoyances one year later when I moved to a different OS and noticed newgen pack doesn't work in it.

BTW vJass is broken because the guy who wrote the compiler had no idea of what grammars, AST trees and lexers are back when he started the project. So please avoid doing anything at all if you don't know about them, for your sanity and for everyone else's sanity . (not saying you don't know, I hope you do).

I would try writing a better vJASS compiler instead of a new language

I've been doing that, kind of.

 

[Lyerae]

I think I see the point for using //! instead of #.

> I've been doing that, kind of.

If you come out with it soon enough, we may not need this new language, honestly... Especially if you fix the flaws/bugs vJASS has.

 

[GetTriggerUnit-]

If I can parse it correctly.

> local/set = no ( )
function call = ( )

 

[Vexorian]

I think I see the point for using //! instead of #.

> I've been doing that, kind of.

If you come out with it soon enough, we may not need this new language, honestly... Especially if you fix the flaws/bugs vJASS has.

Many of the bugs in vJass are actually the existence of features that nobody really needs and the fact that they don't work 100% because there is little testing in regards to those issues.

I always hoped for a language alternative to come up. However, cJass was doomed since the beginning (people that think ASM is a good language to code a compiler should be banned from designing languages) . And other projects never ever happened (EF are you reading this?). And Nestharus is probably going to fail his class. If you really want a language of your own and actually know better about these things than when jasshelper started please do it...

BTW. Whoever told you about text parsing being easier in Perl was right, but he is a nutjob and you should ignore him. You are not doing text parsing, you are doing compiling , and Perl is a terrible language for about anything else (which includes the ability to mantain its code) so on the long term it is a very bad idea.

 

[Lyerae]

I'm sure making it in Perl would be easier than C++.

 

[ertaboy356b]

How about Ruby?? Does anyone consider Ruby?

 

[tooltiperror]

Do a WINE/ZINC abbreviation, with IN in the middle, meaning IS NOT.

VINL - Vinl is not Limited

 

[Narks]

this is what function overloading should look like

// #1
function MyFunc takes integer a returns integer
    return a + a
endfunction

// #2
function MyFunc takes integer a, integer b returns integer
    return a + b
endfunction

function DoStuff takes nothing returns nothing
    call MyFunc(3)
    call MyFunc(5,6)
endfunction

// not valid, because arguments are the same as #1
function MyFunc takes integer a returns nothing
    call BJDebugMsg("the game.")
endfunction

 

[Vexorian]

I'm sure making it in Perl would be easier than C++.

Haha.

both are equally bad choices. Oh wait, no, Perl is a terrible choice, it is the worst thing you could possible imagine and honestly people should just stop using it.

C/++ has flex and bison ...

You should be thinking something like ruby , python or Java. Specially if you want cross platform and you also plan the project to last more than 1 month.

Well, actually just picking the language you are most comfortable with is the way to go. Unless that language is Perl in which case you'll have seizures when trying to update the project, so that's not a good idea. Oh and if you use a .net language your project would earn a guaranteed direct opposition from me and... I don't think you really want that.

 

[Narks]

Visual basic dot net

fuck yeah

 

[Lyerae]

Visual Basic is one of the worst language I've ever seen.
It's syntax is ugly as hell.

> How about Ruby?? Does anyone consider Ruby?

After what Vexorian said, I did consider it, then decided not to.
At this point, I think I'm just going to screw it and use Python. I already know some Python, and it's
be much easier to catch up on what I don't know, than to learn a whole to language, which is what I tried with C, C++, and Perl.

However, I think I need to time to actually decide how the parser itself is going to work, and how the features are to be implemented.
I haven't even worked on the definition for the language. I've just been trying to decide on the language to write the parser in.

I've still got a lot to do. Figure out how to do efficient stuct/class (de)allocation, how to parse globals, whether to do {} blocks, or end* (* being the name of whatever the declaration is. Like function).

I'll update when I've made some progress.

(PS: I'm officially naming the language Onyx.)

 

[GetTriggerUnit-]

this is what function overloading should look like

// #1
function MyFunc takes integer a returns integer
    return a + a
endfunction

// #2
function MyFunc takes integer a, integer b returns integer
    return a + b
endfunction

function DoStuff takes nothing returns nothing
    call MyFunc(3)
    call MyFunc(5,6)
endfunction

// not valid, because arguments are the same as #1
function MyFunc takes integer a returns nothing
    call BJDebugMsg("the game.")
endfunction

This is a very important thing, that must be implemented.

Simple to do. Example.

function HelloWorld takes integer index1, integer index2 returns integer
endfunction

*once parsed*....

function HelloWolrd_i_i takes integer index1, integer index2 returns integer
endfunction

The two 'i' are the first letters of the two parameters, integer, integer.

 

[tooltiperror]

Can you make it so that we can still use 2D arrays?

Also, sounds crazy, but if you implement, Stay with me, Three Dimmensional Arrays, and break the size limit, you could do crazy shit.

 

[Sevion]

Can you make it so that we can still use 2D arrays?

Also, sounds crazy, but if you implement, Stay with me, Three Dimmensional Arrays, and break the size limit, you could do crazy shit.

Technically, you already "can" do 3D arrays, you just have to do this (if I'm not being retarded from lack of sleep):

Array[#_OF_ROWS * ROW_YOU_WANT + #_OF_COLUMNS * COLUMN_YOU_WANT + #_OF_CELLS * CELL_YOU_WANT]

Size of Array would be Rows * Columns * Cells * # of slots.

It gets complicated, but it works.

It'd get extremely large very fast.

Let's say you wanted 10 rows per player, 10 columns per row, and 10 cells per column for 12 players?

10*10*10=1000

1000*12=12000

That already exceeds the maximum by 4000. However, even if the array limit is "broken" by Onyx, I don't think 3D arrays would be necessary.

 

[GetTriggerUnit-]

You can, at the moment, break the size limit.

[lJASS]private integer array Fun[9000][/lJASS]

http://www.wc3c.net/vexorian/jasshelpermanual.html#storarray

2D arrays are supported also.

[lJASS]private integer array Fun [10][20][/lJASS]

http://www.wc3c.net/vexorian/jasshelpermanual.html#storarray

 

[Azlier]

vJass 2D arrays are broken. They never actually work for me, so I have to make them manually.

 

[Xienoph]

Would you want a brand new language, which has all the features that vJASS currently has (and cJASS, possibly.), built into a fast compiler, which has as few as possible bugs (hopefully, at least.).

Sure. But don't add all features that vJASS has, since some features can duplicate another (e.g.: struct duplicating libraries)

I haven't programmed in JASS / vJASS for that long, but here are some pain points I noticed:

1. local declarations have to be made at the start of the function. If you have a local variable used only in one if branch we shouldn't need to find the start of the function block and put the declaration there.

2. Lack of curried functions. Suppose you have a triggered spell that causes all units around the caster to follow the caster (doesn't make sense, but whatever ;p). You'll do something like:

globals
    private unit tmpCaster
endglobals

function followCaster takes nothing returns nothing
    call IssueTargetOrder(GetEnumUnit(), "move", tmpCaster)
endfunction

// This is the trigger action
function follow takes nothing returns nothing
    local group grp = GroupEnumUnitsInRange(GetTriggerUnit(), 500, null)
    set tmpCaster = GetTriggerUnit()
    call ForGroup(grp, function followCaster)
    call DestroyGroup(grp)
endfunction

Using "tmpCaster" is kinda risky here. This library (or struct) can contain another spell that can modify tmpCaster while "follow" is still running. This can make the units in grp follow a unit other than tmpCaster. Also, for someone who's new to the code, "tmpCaster" doesn't really mean anything. I can rename that variable to be "tmpCasterOfFollow" but that makes the variable long and tedious. Instead, we should be able to write the code without using any temporary global variables.

My suggestion would be something like:

// We add another input argument to followCaster
function followCaster takes unit caster, nothing returns nothing
    call IssueTargetOrder(GetEnumUnit(), "move", caster)
endfunction

// This is the trigger action
function follow takes nothing returns nothing
    local group grp = GroupEnumUnitsInRange(GetTriggerUnit(), 500, null)
    call ForGroup(grp, function followCaster(GetTriggerUnit()))
    call DestroyGroup(grp)
endfunction

Why the odd syntax? Well, I'm borrowing the concept from functional language. You can treat followCaster's type to be: unit -> nothing -> nothing (Function that takes a unit and returns a function that takes and returns nothing). So if you call followCaster(GetTriggerUnit()), it returns a function of type nothing -> nothing. This doesn't break the type system, since the type of "followCaster(GetTriggerUnit())" is still a function.

Also, you can still recycle followCaster by calling

local unit u = someone
call followCaster(u)()

How does that work? followCaster(u) returns this function:

function followCaster takes nothing returns nothing
    call IssueTargetOrder(GetEnumUnit(), "move", u)
endfunction

So followCaster(u)() will call that function. Unfortunately, GetEnumUnit can return null if we haven't set it. So that brings me to:

3. Make handlers pass in the event objects through input argument. In the example above, since we use "GetEnumUnit" in followCaster, if we want to reuse followCaster outside ForGroup enumeration, we have to set the tmpCaster and enumUnit global variables. This is dangerous since these variables are required but the compiler can never catch them.

If we make the ForGroup pass in the enumUnit variable to the function, we can rewrite followCaster as something like:

// We add another input argument to followCaster
function followCaster takes unit caster, EnumUnit follower, nothing returns nothing
    call IssueTargetOrder(enumUnit, "move", caster)
endfunction

// This is the trigger action
function follow takes nothing returns nothing
    local group grp = GroupEnumUnitsInRange(GetTriggerUnit(), 500, null)
    call ForGroup(grp, function followCaster(GetTriggerUnit()))
    call DestroyGroup(grp)
endfunction

Now, we can reuse that function by calling

call followCaster(caster)(follower)()   // See #2's explanation for the strange syntax

Why use EnumUnit type? Well, for Trigger handlers, there is a large number of global variables available for the handlers. We can't possibly list them all in the function argument. So those types are indicators to the compiler that it needs to replace the unit input argument by GetEnumUnit() if it is unspecified.

Obviously, the syntax needs a lot of cleaning up: to call a function with 7 variables, you need to have 7 pairs of parenthesis? :nuts: Also, the type of the function argument of ForGroup is unclear. Is it "nothing -> nothing"? Or is it "unit -> nothing"? This depends on how the handler is declared so I'm not so sure if this is a good idea, especially if you consider a more complicated case like trigger handlers.

Those are the most common painful situations I encountered when working on my map. It would be nice if the new language would address those issues.

If you're short of developers, I'll be happy to help you .

 

[Lyerae]

1. Are you saying you want free-form locals?
2. Not sure what your saying there....

> If you're short of developers, I'll be happy to help you.

Know any Python?