Odd script behaviour (aka Beware of Inline Coding)

Anything beyond the basics in using the LiveCode language. Share your handlers, functions and magic here.

Moderators: Klaus, FourthWorld, heatherlaine, robinmiller, kevinmiller

Post Reply
MadDogDean
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 20
Joined: Thu Jan 03, 2013 6:33 pm
Location: Floating in the binary mist

Odd script behaviour (aka Beware of Inline Coding)

Post by MadDogDean » Thu Jan 28, 2016 5:43 am

Hello all,

Running through the Notes Building App course. Just had a row of pulling out a good portion of my hair. "Why, oh why doesn't it work??! Arghhh!!!!"

I discovered (is it by design or bug??) that this will compile fine, but doesn't work as intended. Although the internal "end if" is missing the Script editor has no problem with it.

Code: Select all

   if tNoteID is empty then
      put getUUID() into tNoteID
   else

      -- inline statement below
      if deleteNote(tNoteID, tNotesFile) = 0 then answer "Error saving note." 
      -- with no "end if" it will compile fine

      exit mouseUp      
     
   end if
But, split the line on two lines and it fails to compile (as expected)

Code: Select all

   if tNoteID is empty then
      put getUUID() into tNoteID
   else

      -- inline statement broken
      if deleteNote(tNoteID, tNotesFile) = 0 then
      answer "Error saving note." 
      -- will not compile with missing "end if"

      exit mouseUp      
     
   end if
Not earth-shattering, but hopefully it'll help someone else.

Cheers,
MadDogDean

dunbarx
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 6228
Joined: Wed May 06, 2009 2:28 pm
Location: New York, NY

Re: Odd script behaviour (aka Beware of Inline Coding)

Post by dunbarx » Thu Jan 28, 2016 5:52 am

Hi.

The first handler is properly formed. Not sure what you are seeing.

You are missing an "end if" in the second handler, at the end.

Note, in general, the many ways to construct if-then clauses are not quite perfect, at least as far as automatic indentation goes. This goes back nearly 30 years, to HC days.

If in doubt, do it long-hand, especially not compressing interior if-then clauses. Though it takes more space, the compiler is always happier, and readability is usually greater.

Craig Newman

MadDogDean
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 20
Joined: Thu Jan 03, 2013 6:33 pm
Location: Floating in the binary mist

Re: Odd script behaviour (aka Beware of Inline Coding)

Post by MadDogDean » Thu Jan 28, 2016 6:15 am

Hi Craig,

What I was getting at is that the seemingly identical code (except for one CR) is handled differently by the compiler. I hadn't really expected the compiler to differentiate between a CR in sample 1 or 2.

In LiveCode, is there a difference between an if...then on a single line vs. if...then on two lines?

Using the in-line style wasn't intentional, just a slip of the keyboard, but quickly it can cause a problem with no indication of an error.

Cheers,
MadDogDean

Dixie
Livecode Opensource Backer
Livecode Opensource Backer
Posts: 1336
Joined: Sun Jul 12, 2009 10:53 am
Location: Bordeaux, France

Re: Odd script behaviour (aka Beware of Inline Coding)

Post by Dixie » Thu Jan 28, 2016 7:37 am

The first 'if' statement is looking for 'end if'... You could have constructed your handler :-

Code: Select all

   if tNoteID is empty then
      put getUUID() into tNoteID
   end if
   
   if deleteNote(tNoteID, tNotesFile) = 0 then
      answer "Error saving note." 
      exit mouseUp      
   end if
or to use 'else if'...

Code: Select all

on mouseUp
   if tNoteID is empty then
      put getUUID() into tNoteID
   else if deleteNote(tNoteID, tNotesFile) = 0 then
      answer "Error saving note." 
      exit mouseUp      
   end if
end mouseUp``
See the difference >

MadDogDean
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 20
Joined: Thu Jan 03, 2013 6:33 pm
Location: Floating in the binary mist

Re: Odd script behaviour (aka Beware of Inline Coding)

Post by MadDogDean » Thu Jan 28, 2016 8:10 am

Hi Dixie,

Thanks for your input as well. I guess I wasn't clear on what I was getting at. It was more of an observation than solving an actual problem.

Where my confusion came in was with the compiling of the inline if...then statement.

For example, this works and compiles:

Code: Select all

on mouseUp
   if 0 = 0 then answer "Good job"
end mouseUp
This doesn't compile (and the only difference is the CR after the "then") and we get a "button "Button": compilation error at line 4 (if: missing 'end if'), char 1" error message

Code: Select all

on mouseUp
   if 0 = 0 then 
   answer "Good job"
end mouseUp
Cheers,
Dean

Klaus
Posts: 11262
Joined: Sat Apr 08, 2006 8:41 am
Location: Germany
Contact:

Re: Odd script behaviour (aka Beware of Inline Coding)

Post by Klaus » Thu Jan 28, 2016 10:23 am

Hi Dean,

that's the way the enigne works! :D

If you have "if...then..." in ONE line, it will compile!
If you add a CR after "then" then an "end if" is mandatory.

I ALWAYS use END IF, even if I could use a one-liner, since this is better readable at one glance!
And I NEVER could get accustomed to any "elseif" clauses.


Best

Klaus

Martin Koob
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 237
Joined: Sun May 27, 2007 8:19 pm

Re: Odd script behaviour (aka Beware of Inline Coding)

Post by Martin Koob » Thu Jan 28, 2016 2:14 pm

Another odd thing about 'if ... then..' in one line is when you are in debug mode.

As you are stepping through the code it takes two steps to get past the one line 'if..then..' so the debugger is treating it as two lines.

Martin

SparkOut
Posts: 2028
Joined: Sun Sep 23, 2007 4:58 pm

Re: Odd script behaviour (aka Beware of Inline Coding)

Post by SparkOut » Thu Jan 28, 2016 8:57 pm

Klaus wrote:Hi Dean,

that's the way the enigne works! :D

If you have "if...then..." in ONE line, it will compile!
If you add a CR after "then" then an "end if" is mandatory.

I ALWAYS use END IF, even if I could use a one-liner, since this is better readable at one glance!
And I NEVER could get accustomed to any "elseif" clauses.


Best

Klaus
me too, exactly. Even though I understand those constructions, I don't feel comfortable with the idea of writing code like that.

MadDogDean
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 20
Joined: Thu Jan 03, 2013 6:33 pm
Location: Floating in the binary mist

Re: Odd script behaviour (aka Beware of Inline Coding)

Post by MadDogDean » Fri Jan 29, 2016 3:11 am

Hey, I'm with you all. Spell it out and it makes a lot more sense (especially when you come back to it in 6 months to make a change!)

Here's one I remember coming across when I was doing some PHP work a short while ago. It was to determine thenumber of days in a given month.

Follow it through and it makes sense, but do this with some sort of data you're not familiar with and it'll flash one of those "Huh??!?" moments

Code: Select all

$days = ($month == 2 ? ($year % 4 ? 28 : ($year % 100 ? 29 : ($year %400 ? 28 : 29))) : (($month - 1) % 7 % 2 ? 30 : 31)); //returns days in the given month
Cheers,
MadDogDean

jacque
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 5136
Joined: Sat Apr 08, 2006 8:31 pm
Location: Minneapolis MN
Contact:

Re: Odd script behaviour (aka Beware of Inline Coding)

Post by jacque » Fri Jan 29, 2016 5:56 am

Klaus wrote:I ALWAYS use END IF, even if I could use a one-liner, since this is better readable at one glance!
And I NEVER could get accustomed to any "elseif" clauses.
I had a near-disagreement with Jerry Daniels about this one time. He's with you, Klaus, he always puts if/end if statements around every conditional. I'm a one-liner whenever possible. I've been doing that since HC and it's second nature to me. I don't have any trouble understanding it, and it makes the code more compact. If the statement is long, I sometimes use 2 lines. Otherwise, I block it out with if/end if.

In case anyone in this thread doesn't know, this form is also okay:

if whatever
then something -- 2 lines

Else-ifs aren't much different than case statements in a switch block, only more verbose. If there are only two or three things, I use if/else if. If there's more, I use switch, usually.

So we have three ways to write "if" statements:

Code: Select all

One line:
   if whatever then something

Two lines: 
  if whatever
  then something

Three or more lines:
  if whatever then
    something
  end if

if whatever then
  something
else if someOtherThing
  somethingElse
else
  lastThing
end if
Personal style. Probably no one else could work with my scripts. ;) The main thing is that each of us understands it ourselves.
Jacqueline Landman Gay | jacque at hyperactivesw dot com
HyperActive Software | http://www.hyperactivesw.com

Lagi Pittas
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 327
Joined: Mon Jun 10, 2013 1:32 pm

Re: Odd script behaviour (aka Beware of Inline Coding)

Post by Lagi Pittas » Fri Jan 29, 2016 9:03 pm

HI All,

I'll go into "Craig" or "Simon" Mode :wink:

put the following in a button script and <press>

on mouseUp

Code: Select all

   if true then add  10  to tvar ;  answer( "tvar = TEN : " && tVar ) ;   add 5 to tVar;  put " tvar = fifteen" && tvar
   
end mouseUp
This isn't a mistake - it was specifically programmed that way.

The Parser uses <return> or CR or space as a statement separator and terminator as opposed to "C" that uses semicolon as a statement separator (from memory :? ) so if you have multiple statements on 1 line in C you need to separate them with a semicolon. JavaScript has its ASI (Automatic Semicolon Insertion) and does just that - But Hypertalk was there first.

Try the following code

Code: Select all

on mouseUp

   if true then add  10  to tvar   answer( "tvar = TEN : " && tVar )    add 5 to tVar put " tvar = fifteen" && tvar  if 1=1 then answer "false" 
   
end mouseUp
It works as expected although adding a final else clause discombobulates the Parser and executes the final else instead of the true ( 1=1)

The reason splitting the line fails is that the then is the start of a statement (compound statement) terminated by the end if. But you have premature termination (pun intended!) with the end of line.

It's a matter of style and mostly I use the long form but rules are made to be broken ....

for example

Code: Select all

   if a = 1 then dothis
   if a = 2 then dothat
   if a = 3 then dotheother
Sometimes its clearer than any switch/case statement and shorter and who cares about a few extra tests the compiler has to execute and the extra few bytes of code.


Lagi

dunbarx
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 6228
Joined: Wed May 06, 2009 2:28 pm
Location: New York, NY

Re: Odd script behaviour (aka Beware of Inline Coding)

Post by dunbarx » Fri Jan 29, 2016 10:47 pm

I will go into Lagi mode.

He is utterly correct. Readability, which always (eventually) translates into manageability, is more important than compactness, or wordiness for that matter. The matter of style is personal, and as good as the person.

Klaus likes open multi-liners. One advantage there is that one can add or delete lines of code directly into the local clause of interest. This is really, really compelling.

I like one-liners like Jacque does, whenever I can get away with them. But she and I go way, way back.

Craig

jacque
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 5136
Joined: Sat Apr 08, 2006 8:31 pm
Location: Minneapolis MN
Contact:

Re: Odd script behaviour (aka Beware of Inline Coding)

Post by jacque » Sat Jan 30, 2016 7:30 pm

The Parser uses <return> or CR or space as a statement separator and terminator as opposed to "C" that uses semicolon as a statement separator (from memory :? ) so if you have multiple statements on 1 line in C you need to separate them with a semicolon. JavaScript has its ASI (Automatic Semicolon Insertion) and does just that - But Hypertalk was there first.
LC also accepts semicolons as a statement delimiter. If you use semicolons you don't need the leading spaces.

Edit:
if a = 1 then dothis
if a = 2 then dothat
if a = 3 then dotheother
This requires the parser to examine every line. Using "else if" avoids that and is faster since it acts much as a switch statement and will exit the block as soon as the first match is found.
Jacqueline Landman Gay | jacque at hyperactivesw dot com
HyperActive Software | http://www.hyperactivesw.com

Lagi Pittas
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 327
Joined: Mon Jun 10, 2013 1:32 pm

Re: Odd script behaviour (aka Beware of Inline Coding)

Post by Lagi Pittas » Sat Jan 30, 2016 9:26 pm

Hi Jacque,

In fact I had a longer response that listed the code with the semicolons as well but even with semicolons the else does not work on a single line, and although I could remember that in BASIC (BBC BASIC i'm 100% sure but not VB or others) the" if then else" conditional can be on 1 line.

As I say, I stick with the verbose version but i'm not dogmatic about it. I did most of my business programming on the Apple ][ using UCSD Pascal and always found Pascal to be one of the most readable languages especially after COBOL, FORTRAN and BASIC prior to Pascal.

I've now got past the PUT A into B syntax of LC and the lack of dot notation to be very comfortable with it now - that's what stopped me giving LC a real go for about 6 or 7 years :( after Microsoft stopped developing FoxPro in 2004. Although I still write programs in it when needed -
If all you have is a Hammer everything looks like a nail
- I still use Delphi and Python or whatever when a library is available that does what I need - horses for courses.

Anyway "It isn't Odd behaviour", it's flexibility and it's upto the programmer to decide what to use, how and when.
Rules are meant to be broken - especially your own
Lagi

Post Reply

Return to “Talking LiveCode”