Discussion Total JassHelper overhaul project

[Narks]

make the language like java, since vjass has a lot of similarities to it

 

[Bribe]

Updated the first post with a ton of new changes planned. Here's King's typecasting library in Luck:

//////////////////////////////////////////
//       Typecasting 2.0.1
//       by kingking
//  
//  This library provides some type
//  converting functions.
//
//  ====================================
//   Functions provided :
//  ====================================
//  Agent2Widget(agent) -> widget
//  Agent2Group(agent) -> group
//  Agent2Trigger(agent) -> trigger
//  Agent2Timer(agent) -> timer
//  Agent2Location(agent) -> location
//  Agent2Effect(agent) -> effect
//  Agent2Unit(agent) -> unit
//  Agent2Item(agent) -> item
//  Widget2Unit(widget) -> unit
//  Widget2Destructable(widget) -> destructable
//  Widget2Item(widget) -> item
//
//  Due to the usage of CovertFogState in hashtable, I2X
//  is available again.
//  
//  Int2Widget(integer) -> widget
//  Int2Destructable(integer) -> destructable
//  Int2Item(integer) -> item
//  Int2Unit(integer) -> unit
//  Int2Ability(integer) -> ability
//  Int2Timer(integer) -> timer
//  Int2Trigger(integer) -> trigger
//  Int2TriggerCondition(integer) -> triggercondition
//  Int2TriggerAction(integer) -> triggeraction
//  Int2Force(integer) -> force
//  Int2Group(integer) -> group
//  Int2Location(integer) -> location
//  Int2Rect(integer) -> rect
//  Int2Sound(integer) -> sound
//  Int2Effect(integer) -> effect
//  Int2UnitPool(integer) -> unitpool
//  Int2ItemPool(integer) -> itempool
//  Int2Quest(integer) -> quest
//  Int2QuestItem(integer) -> questitem
//  Int2DefeatCondition(integer) -> defeatcondition
//  Int2TimerDialog(integer) -> timerdialog
//  Int2Leaderboard(integer) -> leaderboard
//  Int2Multiboard(integer) -> multiboard
//  Int2MultiboardItem(integer) -> multiboarditem
//  Int2Trackable(integer) -> trackable
//  Int2Dialog(integer) -> dialog
//  Int2Button(integer) -> button
//  Int2TextTag(integer) -> texttag
//  Int2Ubersplat(integer) -> ubersplat
//  Int2Region(integer) -> region
//  Int2FogState(integer) -> fogstate
//  Int2FogModifier(integer) -> fogmodifier
//////////////////////////////////////////
library Typecasting requires Array

    define DATA = Array{}
    
    public procedure Typecast{parent, return}
        ptype = lower{parent}
        rtype = lower{return}
        write
            public $rtype$ $parent$2$return$($ptype$ object)
                DATA.set$parent$(0, object)
                return DATA.get$return$(0)
    
    Typecast{"Agent", "Widget"}
    Typecast{"Agent", "Group"}
    Typecast{"Agent", "Trigger"}
    Typecast{"Agent", "Timer"}
    Typecast{"Agent", "Location"}
    Typecast{"Agent", "Effect"}
    Typecast{"Agent", "Unit"}
    Typecast{"Agent", "Item"}
    Typecast{"Widget", "Unit"}
    Typecast{"Widget", "Destructable"}
    Typecast{"Widget", "Item"} //The best one
    
    public procedure TypecastI2X{name}
        type = lower{name}
        write
            public $type$ Int2$name$(int id)
                DATA.setFogState(0, ConvertFogState(id))
                return DATA.get$name$(0)
    
    TypecastI2X{"Unit"}
    TypecastI2X{"Effect"}
    TypecastI2X{"Trigger"}
    TypecastI2X{"Timer"}
    TypecastI2X{"Widget"}
    TypecastI2X{"Group"}
    TypecastI2X{"Location"}
    TypecastI2X{"Item"}
    TypecastI2X{"Destructable"}
    TypecastI2X{"TriggerCondition"}
    TypecastI2X{"TriggerAction"}
    TypecastI2X{"Force"}
    TypecastI2X{"Rect"}
    TypecastI2X{"Sound"}
    TypecastI2X{"UnitPool"}
    TypecastI2X{"ItemPool"}
    TypecastI2X{"Quest"}
    TypecastI2X{"QuestItem"}
    TypecastI2X{"Trackable"}
    TypecastI2X{"Dialog"}
    TypecastI2X{"Button"}
    TypecastI2X{"TextTag"}
    TypecastI2X{"Image"}
    TypecastI2X{"Ubersplat"}
    TypecastI2X{"Region"}
    TypecastI2X{"FogModifier"}

 

[lep]

[...]

• Textmacros totally redefined to give maximum functionality. You can basically define your own compile-time rules now.

[...]

I'm no expert but if you want a self-programmable programming language, you should at least seek some inspiration from Lisp [1].

Lisp is a programmable programming language.

One of the key-features of Lisp is the syntax, or rather the lack thereof.
In combination with Macros [2] you pretty much get your ,,own compile-time rules´´.

Having such a system has other interesting consequences: one could provide unit-data or even generate object-data right from your code.

Sure, the syntax is not for everybody so maybe you should have a look at Perl6 [3], Dylan [4] and Haskell [5]. Tha Haskell link stands a bit out since in Haskell you can't really define new blocks but new operators [6]. If this is a good idea one has to decide on their own.
Compiling other ideas from Haskell to $new_jass_language is probably not possible.

__________
[1] http://en.wikipedia.org/wiki/Lisp_(programming_language)
[2] http://en.wikipedia.org/wiki/Common_Lisp#Macros
[3] http://en.wikipedia.org/wiki/Perl_6_rules
[4] http://wiki.opendylan.org/wiki/view.dsp?title=Macros&v=1
[5] http://en.wikibooks.org/wiki/Haskell/More_on_functions#Infix_versus_Prefix
[6] http://www.haskell.org/haskellwiki/Ternary_operator

 

[PurgeandFire]

That [ljass]"$var"[/ljass] thing seems kind of extraneous to me. Generally, I don't think you should add too many things like that, or else the code might lose its explicitness/readability.

In my opinion, readability is something you should constantly consider when coding this, else many people will go in disfavor of it. It looks pretty neat for the most part atm, but if too many keywords/characters become involved, it might end up having the same fate as cJASS. ;P

 

[tooltiperror]

>sigils @ PurgeandFire
it's a textmacro (procedure)

I always wanted to make something like this, but never had the skill.

 

[PurgeandFire]

I was referring to this:

Placing a "$" token within a ""-type string will treat the following segment as an I2S or R2S or basic string with concatenation.

From the first post. I guess I should have been more clear.

 

[tooltiperror]

It's the same as in PHP, ' versus ".

 

[kingkingyyk3]

I still prefer vJass.

 

[Darthfett]

I waited to vote on the poll, because I thought something like this was gonna happen. I personally think a lot of these changes are not good changes at all. I'd prefer to see the old vJASS syntax than this weird syntax. I think if you were to create a new poll, there would be far fewer 'yes, update it' votes, once they see that you're not merely updating the language, but making a new one.

 

[Narks]

frankly, I think that using indents to structure code is an abomination and should be killed with fire

 

[Bribe]

The syntax highlighting is what kills it. When properly highlighted it is a work of beauty (Notepad++ syntax highlighting). The syntax is obviously unfinished, I still have some beautification I want to finalize with it to give it the extra nudge towards that "x" factor. For now I think I should strip out the JASS highlighting attempt so nothing looks out of place.

>> That "$var" thing seems kind of extraneous to me. Generally, I don't think you should add too many things like that, or else the code might lose its explicitness/readability.

The $ token is found in many other programming languages and makes it extremely quick to type out debug messages and also avoids very annoying syntax errors.

print "$bottles bottles of beer on the wall, $bottles bottles of beer, take one down, pass it around, $(bottles - 1) bottles of beer on the wall"
 
//versus
 
call BJDebugMsg(I2S(bottles) + "bottles bottles of beer on the wall, " + I2S(bottles) + " bottles of beer, take one down, pass it around, " + I2S(bottles - 1) + " bottles of beer on the wall")

>> I'm no expert but if you want a self-programmable programming language, you should at least seek some inspiration from Lisp.

It's going to allow far more configurable "textmacros" that JassHelper has never been able to do, but writing an entire language within Luck is not the idea.

vJass will be supported in the future, but currently I will be writing in Luck. I did not include the {} operators for blocks (I reserved those for procedures) because those are often found in hard-to-reach places on a keyboard (slowing down the writing process), especially on a German keyboard.

Yes, the poll has drifted from its original approach and for that I think I should take the poll down. By popular demand it was suggested to re-write the compiler and that's what I'm doing, deadline the end of next month for a beta at worst.

I also don't understand why anyone has a problem with indentation-based syntax... it's "unreadable"? With vJass you have to type a bunch of bloat on the screen to form endblocks and you end up having to train your eyes to ignore it. It is extremely difficult for me to read improperly indented code as it is, the endblocks have nothing to do with it. It's a nice timesaver and I think it is a very enjoyable way of writing.

 

[Sevion]

The reason everyone doesn't like indentation-based syntax is because it's hard to tell where one block ends and the next starts. We're not used to seeing this and thus can't read it.

To most, the current syntax looks messy and incomplete. It's hard to read.

I say you should keep some kind of end block. Though, not just end or the current "endX" syntax. That would look weird. I think {} would seriously be the best option here.

 

[Bribe]

Thank you for indicating that, I can see what you mean looking at it from that fresh perspective.

I've added colon as a requirement to open up a block statement, like Python has. It's a step in the right direction but I will be contemplating whether it is enough.

 

[Sevion]

It still looks like everything is "free-floating", but it's better.

 

[tooltiperror]

I think the colon stitches it up nicely enough, personally.

Maybe:

library KillSpell:
	define:
		private integer SPELL_ID = 'A000'

	boolean Actions():
		if GetSpellAbilityId()!=SPELL_ID:
			return false
		unit toKill=GetSpellTargetUnit()
		KillUnit(toKill)
		return false

	onInit:
		trigger t=CreateTrigger()
		TriggerAddCondition(t,Condition(Actions))
		integer i=0
		while i < bj_MAX_PLAYERS:
			TriggerRegisterPlayerUnitEvent(t,Player(i),EVENT_PLAYER_UNIT_SPELL_EFFECT)
			i++
		t=null

?

 

[Sevion]

I will have to agree. That does look pretty nice now. It's a pretty good idea to make Luck indentation-based as long as the blocks are easily distinguishable from each other. This will probably be good for fixing those unreadable posts without indentation P

 

[Bribe]

Instead of indenting it eight spaces, I think it's the syntax highlighting that was making it hard to read. It looks very well-structured on my computer at home that has the Notepad++ highlighting. So for the first post, I've stripped out the syntax highlighting and it looks a lot more structured.

 

[Sevion]

That does look better than before.

Not sure what else we could do though.

 

[Bribe]

The rest of the readability likely has to do with TimerUtils being multi-flavored. Have you ever tried reading it in vJass? It's a mess.

Here's a Timer32 that works quite differently than what we're used to:

#luck
library T32:
    /*
        This will print "3; 2; 1" every 0.03125 seconds:
        
            struct myStruct:
                procedure PeriodicLoop():
                    write:
                        print "$this"
                
                T32{"PeriodicLoop"}
                
                onInit:
                    thistype::1.startPeriodicLoop()
                    thistype::2.startPeriodicLoop()
                    thistype::3.startPeriodicLoop()
    */
    define public T32_PERIOD = 0.03125
    
    global:
        public constant int T32_FPS  = R2I(1 / T32_PERIOD)
        public          int T32_Tick = 0
        
        trigger trig = CreateTrigger()
    
    public procedure T32(periodicName):
        include:
            thistype next
            thistype prev
            
            public nothing start$periodicName$():
                debug:
                    if this.prev != 0 or thistype::0.next == this:
                        print "T32 ERROR: Struct #$this had start$periodicName$ called while already running!"
                        return
                thistype::0.next.prev = this
                this.next = thistype::0.next
                thistype::0.next = this
            
            public nothing stop$periodicName$():
                debug:
                    if this.prev == 0 and thistype::0.next != this:
                        print "T32 ERROR: Struct #$this had stop$periodicName$ called while not running!"
                        return
                this.prev.next = this.next
                this.next.prev = this.prev
                this.prev = 0
    
            onInit:
                TriggerAddCondition(trig, Condition(lambda boolean:
                    readonly thistype this = thistype::0.next //Yeah, it's a module-readonly local variable
                    while this != 0:
                        $periodicName${}
                        this = this.next
                ))
    
    onInit:
        TimerStart(CreateTimer(), T32_PERIOD, true, lambda nothing:
            Tick++
            TriggerEvaluate(trig)
        )
#endluck

 

[tooltiperror]

Why make #luck? That's stupid.

You're going to be able to tell Luck from v/JASS/2 pretty easily.