Difference between revisions of "Talk:If"

From Second Life Wiki
Jump to navigation Jump to search
 
(One intermediate revision by one other user not shown)
Line 35: Line 35:
::It's a consequence of the right recursion in the grammar. Mono and LSO use the same grammar, so it's not a surprise that both compute intermediate results in the same order. That's what led to things like integer+-integer being cheaper than integer-integer in Mono (and same with float), because due to the swapped order Mono uses a function call to perform integer and float subtraction and division.--[[User:Sei Lisa|Sei Lisa]] ([[User talk:Sei Lisa|talk]]) 09:09, 31 January 2015 (PST)
::It's a consequence of the right recursion in the grammar. Mono and LSO use the same grammar, so it's not a surprise that both compute intermediate results in the same order. That's what led to things like integer+-integer being cheaper than integer-integer in Mono (and same with float), because due to the swapped order Mono uses a function call to perform integer and float subtraction and division.--[[User:Sei Lisa|Sei Lisa]] ([[User talk:Sei Lisa|talk]]) 09:09, 31 January 2015 (PST)


:::Are you sure about the grammar being right recursive being the cause. I know LSO operands are loaded right then left. Which means you have to compute the right operand before the left. Sure it's right recursive but that's because of how the bytecode is generated, not grammar specific. They had to work extra hard to make Mono work this way, the first Mono versions didn't do this at all. -- '''[[User:Strife_Onizuka|Strife]]''' <sup><small>([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]])</small></sup> 14:55, 31 January 2015 (PST)
:::That's one part of it, but just because you right recurse doesn't mean you have to use RtL for operands. -- '''[[User:Strife_Onizuka|Strife]]''' <sup><small>([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]])</small></sup> 14:55, 31 January 2015 (PST)
 
::::The parse tree decides the operand computation order, not to be confused with evaluation order. For example, with right recursivity a+b-c is computed as push c, push b, push a, add, subtract in reverse. The operands are computed right to left, but the expression is evaluated left to right. If the operands can be computed in a different order than what the parse tree represents without major effort such as manipulating the tree to invert it, I'd be interested in knowing how.--[[User:Sei Lisa|Sei Lisa]] ([[User talk:Sei Lisa|talk]]) 19:47, 31 January 2015 (PST)

Latest revision as of 19:47, 31 January 2015

I would appreciate an example that shows the appropriate "if / elseif / else" construction. I assume that this will work:

 if (a == "Loren") {
   llSay(0, "Lorem ipsum sic amet!");
 } else if (a == "Bob") {
   llSay(0, "Babble dabble rabble rouse.");
 } else {
   llSay(0, "Gobbledygook?  or English?");
 }

- Kendown Baroque 12:12, 29 August 2007 (PDT)



This page is missing documentation on one of the major flaws of the LSL if() else() statement. When writing an if() else(), residents need to know that there is a limit of 23 else() statements (not including the first if() statement). Further documentation of this limitation including a workaround can be found in the if() statement article at http://rpgstats.com/wiki/index.php?=Ifelse . I would add this documentation myself but I'm not sure how or where in the article to add it.

Kaiden Ruxton 23:47, 18 January 2008 (PST)

It looks like this limit is no longer in existence. i tested it with 50 else if and got a friend who tested about 120 without an error in LSL2 or mono. the connected jira VWR-811 is marked as resolved since about a week too. So the info can be removed?
Zai signature.png Lynch (talk|contribs) 03:20, 29 October 2008 (UTC)
Sounds like a good idea then. -- Strife (talk|contribs) 14:01, 29 October 2008 (UTC)


Parsing Right To Left

It seems LSL parses if statements right to left.
Ex: if(a==3 && (a=3) && (a=4))llSay(0, "After statement: "+(string)a);
This will output "After statement: 3" --Jasdac Stockholm (talk) 06:43, 31 January 2015 (PST)

Yes LSL parses statements Right to Left. This is actually a quirk that came out of the original LSO VM bytecodes having their operator operands reversed (the right operand goes on the stack before the left operand). When Mono was introduced, which has operands in the correct order, much effort was made to keep scripts that worked in LSO working in Mono. The exceptions to the RTL rule are lists and control statements (but expressions within those are parsed RTL). I think this might be documented in the operator article. -- Strife (talk|contribs) 08:56, 31 January 2015 (PST)
It's a consequence of the right recursion in the grammar. Mono and LSO use the same grammar, so it's not a surprise that both compute intermediate results in the same order. That's what led to things like integer+-integer being cheaper than integer-integer in Mono (and same with float), because due to the swapped order Mono uses a function call to perform integer and float subtraction and division.--Sei Lisa (talk) 09:09, 31 January 2015 (PST)
That's one part of it, but just because you right recurse doesn't mean you have to use RtL for operands. -- Strife (talk|contribs) 14:55, 31 January 2015 (PST)
The parse tree decides the operand computation order, not to be confused with evaluation order. For example, with right recursivity a+b-c is computed as push c, push b, push a, add, subtract in reverse. The operands are computed right to left, but the expression is evaluated left to right. If the operands can be computed in a different order than what the parse tree represents without major effort such as manipulating the tree to invert it, I'd be interested in knowing how.--Sei Lisa (talk) 19:47, 31 January 2015 (PST)