[fpc-devel] Re: [fpc-l] type discussion

[Hans-Peter Diettrich]

Angelo Bertolli wrote:

> > Begin..End is redundant - you have to indent them to make em readable
> > anyways.
> >
> Not at all; I certainly don't indent them, and I'm a fanatical
> indenter.

Agreed. I really can't understand why some people indent like this:
  if ...
    then
      begin
        ...
      end
    else
      if
...

> I don't think you're going to convince anyone to change THIS
> part of Pascal--it's essential.  You change begin and end, and you just
> don't have Pascal anymore.

Some things could be changed, and have been changed for good reasons, in
subsequent designs (Modula, Oberon). When all arbitrary occurrences of
statement and statement_sequence in the Pascal grammar are replaced by a
unique statement_list, where a statement list is terminated with an
"end", the whole language becomes simpler and much clearer. It also will
eliminate the "dangling else" ambiguity, that exists in the majority of
all existing language designs.

You'll notice the difference neither by looking at the code, written
according to this syntax, nor by simply looking at the grammars. But
you'll notice the difference when you're writing the parsers and find
the semantics actually different from the syntax. In many languages the
syntactical grammar is a simplified and generalized picture of the
semantics, so that the parser has to check for specific cases in many
places. In good designs, as provided by Wirth, no difference between
syntax and semantics can exist.

This unfortunately is no more true for OPL, where optional semicolons
must be introduced into to the syntax in very many places. Then only the
parser can decide, whether in such places a semicolon is actually
mandatory, optional, or illegal, depending on whether a semicolon has
already been consumed by some preceding optional occurence.
Consequentially the meaning of some code can change dramatically, only
depending on the occurence or absence of a semicolon in a specific
place! My favorite example:

case i of
0: if a then b
; //<--- illegal, optional or required?
else c
end;


> > manual memory management of tobjects is redundant as you can get good
> > performance with ref counting tobjects.
> >
> Oh yes, this old argument.  I remember reading this on the list before.
> I guess it's still on your mind ;)  I really don't know about the pros
> and cons for ref counting, so maybe someone can explain it.

Two cons for reference counting:
- It fails on circular references. Fatal :-(
- Counting operations increase with the number of executed statements.

Mark/sweep collections, in contrast, increase with the number of object
creations, not with the number of object uses. But their execution time
depends on the number of existing object references, regardless of
whether objects really can be removed.

Both kinds of garbage collection can work (reliably) only under specific
conditions, which are not satisfied in OPL :-(

DoDi