Any chance of a two-pass compiler or similar approach?

I generally like to lay out programs in this sequence, which doesn't work with a one-pass compiler:

// Start by defining high-level activities, then define the sub-sections later.

// Setup info, get initial input, etc.

Call SetVars
Call GetInitialInput
Call ProcessData
Call PrepareOutput
Call Cleanup
Exit


==================
procedure/function1 // e.g., define variables
end proc/func

Proc/Func2
end proc/func2

Proc/Func3
end proc/func3

====================

As an alternative, WordPerfect Macro Language (which is a full-featured structured programing language) has a "Procedure Prototype" command.  Near the top you just specify the name of the procedure or function and the parameters and return value type.  That way the compiler knows what to expect, so it doesn't give an "undefined procedure/function" error when compiling.

Let's say you had a "DoubleInput" function:


Function Prototype DoubleInput(NumVal as Binary) as Binary

... Rest of the main program ...

Function DoubleInput(NumVal as Binary) as Binary
       Return 2 * NumVal
End Function

========================

One advantage of the Prototype approach is it gives you a neat "table of contents" of procedures and functions near the top, since the prototype definition should only take one line.

Rick_R wrote on Nov 12^th, 2011 at 3:12pm:


You can, of course, follow the "end subroutine" or "end function" statements with a comment on the same line.

function my_func()
   do_stuff()
   do_more_stuff()
end function // my_func()
 

If you are otherwise losing the end of your subroutines or functions, I'd recommend very careful indenting, where the content of every routine is indented a consistent amount, as well as the content of each conditional. The examples in K&R use the following three formats. It is wise to pick one and use it consistently (I prefer the first):

   if(name = "john")
   {
      do_something()   
   }
 

   if(name = "john") {
      do_something()   
   }
 

   if(name = "john")
      {
      do_something()   
      }
 

If the problem is merely the length of a routine, repartitioning your code into smaller routines is strongly recommended. Unless there is a functional imperative toward a contiguous routine (like a conditional with many "else if" conditions), I'd generally recommend that no routine ever exceed 30 lines of code, with only one full statement per line.

There is a no functional advantage in SBasic to resort to code packing.

In-line select:

x = Select(position, Val_1, Val_2, Val_3 ...)

"Position" would have to evaluate to a number. I think the most I have seen for these is around 10 choices. I would think a minimum of 7 (for days of the week) up to possibly 12 (for months).  Like in-line if, one function could be used regardless of the data type being returned.

For instance:

Gender = Select(Position, "Male", "Female", "Unknown", "Multiple")

The last one isn't a joke.  In veterinary medicine the "gender" of a litter is "multiple".

And the Swahili language has six genders including "rock" and "knife", but we won't get into that ...


(... Since I know everyone will ask  ... In grammar, "gender" means "type".  The "rock" "gender" means words that take the same grammatical forms that the word "rock" uses, etc. English is one of only a few languages where the gender of a noun is normally the same as the gender of the actual item.)

The purpose of in-line select (or, alternatively, "case" or "switch", depending on the language) and in-line if is to avoid having to write custom procedures, create arrays, etc., where you simply want to say "Based on the contents of this variable (or logical evaluation), return this value." For instance, say you wanted to return the name of the day in Spanish.  Yes, you could write an array, or a multi-line If comparison, etc., but it would be a lot easier to just have DayName = Select(DOW, "Domingo", "Lunes", "Martes", "Miercoles", etc.)

As I mentioned, I have written a set of "in-line if" functions, but it requires a separate one for each data type:

     IifStr() String -  in-line if returns first string if condition is true, else second

     IifChar() Char - in-line if returns first character if condition is true, else second (etc.)
     IifDate()
     IifTime()
     IifInt()
     IifDouble()
     IifMoney()

FoxPro has both and it makes programming much easier.  Often something can be done with a single line of code interactively that requires an entire subroutine in most other languages--often just because they lack an in-line if or an in-line select function, so a full-blown CASE A ... CASE B ... DEFAULT ... END CASE structure has to be used.

Whether it is in-line if or in-line select, they shouldn't be just for strings, e.g., Bonus = Select(YearsOfService, 200, 500, 1000, 1500) or whatever.

... And for that example, you would probably want to nest an in-line if so that:

Bonus = Select(iif(YearsOfService < 4, YearsOfService, 4), 200, 500, 1000, 1500)

Hammer wrote on Nov 19^th, 2011 at 2:27pm:


That's funny.  You all speak lots of languages.

Back in the dark ages when I was young my parents asked a school counselor if I should be taking a foreign language,

They said "your sons English is a foreign language". Heck I was from Brooklyn!

Two things;

1.      When running a Quick Report, how about an option to print row and column lines like a spread sheet, when desired, along with the capability to select the color of the lines.

2.      When you press the Delete Record button you currently receive these warnings, “Do you want to permanently delete this [form name] record?” Or, “Do you want to permanently delete this SUBFORM [form name] record?”  Could it be enhanced to include PARENT [form name] record & TAB PAGE [form name] record” - and also have PARENT, SUBFORM and TAB PAGE show in different bolded colors?

laurie wrote on Jan 5^th, 2012 at 10:30pm:


You can copy records between two databases in the same application. To copy to a different application, export from one and import into the other.

In general though, to avoid having the two applications get out of synch with one another, we tend to put a checkbox on the form for Active and uncheck it to make a client inactive. This keeps the records in synch and provides more flexibility with reports. Just my 2 cents.