TinTin++ Mud Client The TinTin++ message board

 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 
TinTin++ Mud Client

#help and 1.99.7 beta

 
Post new topic   Reply to topic    The TinTin++ message board Forum Index -> Bug Reports
View previous topic :: View next topic  
Author Message
Shaiith



Joined: 11 Jul 2009
Posts: 64

PostPosted: Thu Aug 13, 2009 8:21 pm    Post subject: #help and 1.99.7 beta Reply with quote

#help needs to be updated in the beta. #help foreach uses the 1.99.6 syntax.

Code:
#help foreach
################################### FOREACH ####################################

Command: #foreach {list} {variable} {commands}

         For each item in the provided list the foreach statement will update
         the given variable and execute the command part of the statement.

Example: #foreach {bob tim kim} {name} {tell $name Hello}
Back to top
View user's profile Send private message
Scandum
Site Admin


Joined: 03 Dec 2004
Posts: 3796

PostPosted: Thu Aug 13, 2009 9:39 pm    Post subject: Reply with quote

1.99.6 didn't have the foreach command, what exactly is wrong with it?
Back to top
View user's profile Send private message Send e-mail
Shaiith



Joined: 11 Jul 2009
Posts: 64

PostPosted: Thu Aug 13, 2009 9:41 pm    Post subject: Reply with quote

Aren't lists now of the structure

{{key1} {value1} {key2} {value2}}? The list example has odd length, and it's not clear that they're keys/value pairs. It looks like three values.
Back to top
View user's profile Send private message
Scandum
Site Admin


Joined: 03 Dec 2004
Posts: 3796

PostPosted: Thu Aug 13, 2009 10:03 pm    Post subject: Reply with quote

I see. With a list I still mean either a row of values, or a row of keys.

Directly putting a nested variable into #foreach is unlikely to do you any good.

That's why you use $var[] in #foreach to get the keys, and if you want to create a variable that can be inputted in #foreach you do something like: #var friends {{Bob}{1} {Tim}{1} {Bubba}{1}} so $friends[] only displays the names, and $friends[<name>] can be used as a boolean check to see if someone is a friend.
Back to top
View user's profile Send private message Send e-mail
Shaiith



Joined: 11 Jul 2009
Posts: 64

PostPosted: Fri Aug 14, 2009 6:19 pm    Post subject: Reply with quote

The overloading of regular lists and associative lists has interesting consequenses.

A list of lists.
Code:
#var friends {{bob ann} {tim ann} {kim ann}}             
#OK. VARIABLE {friends} HAS BEEN SET TO {{bob ann} {tim ann} {kim ann}}.

#foreach {$friends} i {#foreach {$i} j {#showme here: $j}}
here: bob
here: ann
here: tim
here: ann
here: kim
here: ann
here:

#var friends                                             
#VARIABLE {friends}={{bob ann}{tim ann}{kim ann}{}}


It gets extended to an even number as tintin assumes it's an associative list. The only separators that work for making a list of lists (simple lists, neither depth associative) are {} as anything else will cause the outside foreach to break on spaces.

I'm not sure this is an interesting failure case, it is somewhat annoying that #foreach changes the contents of the item it's looping over if it's an odd length (and it thinks it should be associative due to the presence of {})
Back to top
View user's profile Send private message
Shaiith



Joined: 11 Jul 2009
Posts: 64

PostPosted: Fri Aug 14, 2009 6:21 pm    Post subject: Reply with quote

It appears to make this determination based on the first item in the list

Code:
#var friends {{bob ann} tim kim}                               
#OK. VARIABLE {friends} HAS BEEN SET TO {{bob ann} tim kim}.

#foreach {$friends} i {#foreach {$i} j {#showme here: $j}}
here: bob
here: ann
here: tim
here: kim
here:

#var friends                                             
#VARIABLE {friends}={{bob ann}{tim}{kim}{}}


versus

Code:
#var friends {bob tim {kim ann}}                         
#OK. VARIABLE {friends} HAS BEEN SET TO {bob tim {kim ann}}.

#foreach {$friends} i {#foreach {$i} j {#showme here: $j}}
here: bob
here: tim
here: kim
here: ann

#var friends                                             
#VARIABLE {friends}={bob tim {kim ann}}
Back to top
View user's profile Send private message
Shaiith



Joined: 11 Jul 2009
Posts: 64

PostPosted: Fri Aug 14, 2009 6:28 pm    Post subject: Reply with quote

It becomes a problem if someone has a script such as

Code:
#var gag_items {{mother ducker} motherducker duck}     
#OK. VARIABLE {gag_items} HAS BEEN SET TO {{mother ducker} motherducker duck}.

#foreach {$gag_items} i {#gag *$i*}
#OK. {*duck*} IS NOW GAGGED.
#OK. {**} IS NOW GAGGED.
#OK. {*mother ducker*} IS NOW GAGGED.
#OK. {*motherducker*} IS NOW GAGGED.


Don't ask me why someone would write that code, (gags don't need *, but it was to show how it could go very wrong)

Also reordering of the list could be bothersome if your foreach depends on an inorder execution for a second run, even if executing on an empty list item doesn't cause issues.
Back to top
View user's profile Send private message
Scandum
Site Admin


Joined: 03 Dec 2004
Posts: 3796

PostPosted: Fri Aug 14, 2009 8:27 pm    Post subject: Reply with quote

You can use:

Code:

#list gag_items create {mother ducker} motherducker duck

#loop 1 &gag_items[] i {#gag *$gag_items[$i]*}


Or:
Code:

#foreach {{mother ducker} motherducker duck} i {#var gag_items[$i] 1}

#foreach {$gag_items[]} i {#gag *$i*}


Guess I could add a command to easily create a list of booleans, but not like it's that big an effort to use:

#var gag_items {{mother ducker} 1 motherducker 1 duck 1}
Back to top
View user's profile Send private message Send e-mail
Shaiith



Joined: 11 Jul 2009
Posts: 64

PostPosted: Fri Aug 14, 2009 11:22 pm    Post subject: Reply with quote

It just seems wrong to me that #foreach can a) add an empty element and b) reorder things.

Looping over a variable shouldn't change that variable without an explicit set of some sort.

Much like this great change side effect.

Code:
#var __events[bar] 
#VARIABLE {bar}={{baz}{boo}{foo}{test}}

#list __events[bar] del 1
#LIST DEL: Invalid index: 1

#list __events[bar] del +1

#var __events[bar]       
#VARIABLE {bar}={{1}{test}}


The key for the value test changes from foo to 1.
Back to top
View user's profile Send private message
Scandum
Site Admin


Joined: 03 Dec 2004
Posts: 3796

PostPosted: Sat Aug 15, 2009 9:15 am    Post subject: Reply with quote

#foreach doesn't add an empty element, the empty element is added when you set the variable it goes through the nesting routine.

The elements are ordered alphabetically since it's an associative array, so that's done as the variable is set, not by #foreach. If you don't want the order to change you can use #list and use #loop to go through it.

#list __events[bar] del +1 deletes the first element, rather than element 1.

But you might as well use: #unvar __events[bar][+1]
Back to top
View user's profile Send private message Send e-mail
Shaiith



Joined: 11 Jul 2009
Posts: 64

PostPosted: Sat Aug 15, 2009 11:13 am    Post subject: Reply with quote

Scandum wrote:
#foreach doesn't add an empty element, the empty element is added when you set the variable it goes through the nesting routine.


This happens sometimes, but not always as part of the call to foreach.

Quote:
The elements are ordered alphabetically since it's an associative array, so that's done as the variable is set, not by #foreach. If you don't want the order to change you can use #list and use #loop to go through it.


This also happens sometimes, but not always as a call to foreach.

It's the "sometimes, but not always" semantics that aren't well defined. It makes tintin's interpreted language nondeterministic. Ok, it's deterministing, but a simple reordering of items to a #var when defining a list cause different behavior. Semantically this is a big "huh, why does order matter for nonassociative lists?"

Quote:
#list __events[bar] del +1 deletes the first element, rather than element 1.

But you might as well use: #unvar __events[bar][+1]


So it deletes the first element and the second element has it's key changed from foo to 1? That seems very wrong.

(edit: added comment about how it's not determinism that's breaking, but an implicit semantic assumption)
Back to top
View user's profile Send private message
Scandum
Site Admin


Joined: 03 Dec 2004
Posts: 3796

PostPosted: Sat Aug 15, 2009 1:23 pm    Post subject: Reply with quote

You only get an empy element added if you provide an uneven amount of arguments.

#list maintains the 1 2 3 order so #variable[1] always refers to the first element. It emulates the behavior of a dynamic array.

I think your main problem is that you try to use #list when you shouldn't.
Back to top
View user's profile Send private message Send e-mail
Display posts from previous:   
Post new topic   Reply to topic    The TinTin++ message board Forum Index -> Bug Reports All times are GMT - 5 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
Get TinTin++ Mud Client at SourceForge.net. Fast, secure and Free Open Source software downloads Get TinTin++ Mud Client at SourceForge.net. Fast, secure and Free Open Source software downloads
TinTin++ Homepage

Powered by phpBB © 2001, 2002 phpBB Group