Notes on Syntax

Now don't try to tell me you think symbols are easier, because there aren't enough symbols in the world to cover every operation, much less in the limited PC character sets so I know you use functions in SmTlk/C++/C+@/whatever..

Response:

There is more to the issue than symbols vs. functions. For example, compare these 3 variations:

  copy from table1 to table2 for .rate > .maxrate fieldgroup "12"

  copytable(table1,table2,".rate > .maxrate","12")

  copytable(source="table1", dest="table2", crit=".rate > .maxrate",
        fieldgroup="12")

Or, this:

  with table Table1 {
    .name = "fred"
    .ssn = "123-45-6780"
    .date = "1999/12/31"
    .amount = 12.50
    .reason = 18
    etc...
  }

compared to:

  Table1.field("name").savevalue = "fred"
  Table1.field("ssn").savevalue = 123-45-6780"
  Table1.field("date").savevalue = "1999/12/31"
  Table1.field("amount").savevalue = 12.50
  Table1.field("reason").savevalue = 18
  etc....

Regarding the first set, I find the first one more intuitive than the second because the parameter order is less important and the "from-to" and "for" words offer commonly used action words that provide context clues (roughly barrowed from xbase). The "For" clause is used in multiple xbase commands and it does not matter where it occurs in the command. The second one requires one to keep checking the reference to remember the parameter order and requirements. Thus, the first approach takes advantage of repeating syntax patterns. Few would pick the 3rd option.

Regarding the second example set, I find the first syntax much more pleasant, especially if dealing with a lot of data-intensive (table) programming. Its more compact, less repetitive, and less typing of quotes.

Thus, functions are not always the most efficient way to go, especially for a primary task. This is why I brought up the math example. Special syntax is available for math so that a math programmer does not have to use functions like "times(x,y)" and "plus(x,y)". The newer languages fail to provide similar shorcuts for table access, sticking us with functions instead.

Functions are fine for less-often used constructs or niche libraries. But, they get in the way if they must always be used for the PRIMARY tasks.

Limits of C++ and Java

People keep saying that OOP languages such as C++ and Java can be made to provide the necessary constructs for Table Oriented Programming and ITOP. However, it appears they lack the following abilities:

Ability to evaluate strings with internal functions. This ability is crucial to Control Tables and useful for many other purposes. Although a "side language" can be added to Java and C++, this approach has many limitations. For one, it splits your code between the regular language and the side language where each language has a tough time communicating with the other.
Adequate Context Reduction. This is the ability to avoid redundancy in syntax that repeats itself over large stretches of code. Reducing this repetition not only reduces typing, but also makes the relevant information more visible to the reader, reducing reading errors. The "with table" example above shows an example of Context Reduction. You can also read about variations in our proposed ITOP language discussion. Note that avoiding quotes for field names is also a form of context reduction.
Clause-based syntax. Clause-based syntax is a kind of compromise between position-based parameters and named parameters. The "copy from" example above shows an example of clause-based syntax and discusses some of it's advantages. Some implementation suggestions can be found in our proposed ITOP language discussion.

Main

Doc. Version: 1c - Aug 1998