Re: Can someone spot the error here?

scott moore <nospam@xxxxxxxxxxx> wrote:

frank@xxxxxxxx wrote:

I think this last statment is too strong. It can well be kept in a
register (and often is, in my experience), if the function doesn't
use many other variables, or the machine has many registers (not
everything's a 386 ;-), or the result is used often enough to
warrant giving it its own register.

Sure, the mathematical definition of "function" is short and small.
In Pascal this is preserved.

Kind of. (Mathematical functions don't have side-effects ...)

In C, everything is a function.

Yes, but that's just terminology. If I think of a "void function" as
a "procedure", this doesn't really change the way I program in C.
(Yes, I do think it's strange terminology, but this is just about
the smallest flaw in C IMHO.)

A problem is that what is or is not efficient changes over time.
With the earliest and simplest compilers, an increment statement
("Inc" in BP, "++" in C) might compile to better code than an
addition and assignment ("i := i + 1"). These days are long gone,

Er, before we all jump into bed together, IP Pascal on the Z80 was not
only optimizing +1 style cases, but had power factoring for
multiplication, i.e., *10 = *2*2*2+1+1.

BTW, why not (x*2*2+x)*2?

That was 1980, 2 years before
BP came out.

I didn't mean to imply that all compilers of the time didn't
optimize (that's why I said earliest *and* simplest), and to be
fair, even BP did some easy optimizations, probably including that
"+1" case (don't remember exactly).

Disagree. Its true we are incorporating more high level data and
structures, but that does not mean its free. It mainly means we are
wasting CPU power. BP and 10206's insistence on calling everything
that is a character array a "string" leads to way to much net assembly
code used for common operations that would only require character
array handling. C, for example, has no strings, only character arrays.

Another way to say the same is to use some of those abundant CPU
cycles to save programmer's time. :-) But of course, it's a matter
of taste again.

My programs generally do a lot of string handling, and I really find
string handling in C to be a PITA, and in anything but the most
time-critical sections, I prefer the Pascal (EP, BP) ways.

So I'm fine with it, as long as there's some way to avoid the
implicit operations when you need to save CPU power. And, of course,
BP and EP do let you work on character arrays as arrays if you know
exactly what you do. More precisely, EP only regards some character
arrays as strings, namely those with a nonvarying lower bound of 1
and consisting of "Char" entries and packed. So by intentionally
violating one of these constraints, you can even force the compiler
to treat them as just arrays, e.g. by using an unpacked array (if
the compiler is strict) or an array of "MinChar .. MaxChar" (given
suitable definitions of those).

I know programmers who think (coming from C) that for comfortable
string handling you need, e.g., a script language such as Perl. This
is even more wasteful with CPU cycles (even if compiled, e.g.
because it's runtime-typed). So for programs with both string
operations and tight loops working on integers, I find EP/BP the
ideal combination (programming comfort for the former, efficiency
for the latter).

We're back to the sugar. Of course, it didn't *need* it. The same
can be said about almost any extension. There are few extensions
that are really needed to original Pascal (such as some way to
interface with external code), the rest is a matter of taste.

A good example of an extension that is clearly sugar, but necessary,
was "otherwise" for case statements. I gave up on that one (not
including the feature) because it got very tiring handling C
enumerations that were converted to Pascal, which is pretty much
what has to be done for Windows, Linux, OS X, etc.

True. But actually I find it useful even for pure Pascal code.
Sometimes I need to handle some cases specially and the rest the
same, so it comes handy. Now we don't have to discuss that each
"case" can be replaced with a series of "if ... else", so from this
POV, "case" itself, and "otherwise" that goes with it, is just
sugar. ;-)

Sure, we agree. Extensions that are properly done and don't change
the rules of the original language are cool.

Of course, I'd stress both points. All extensions of EP don't change
the original language, apart from the addition of a few new reserved
words. (Some of them might have been avoidable, but some not -- e.g.
using "else" for "otherwise" as BP did, creates a new kind of
dangling-else problem, and in some cases they really tried to reuse
existing keywords when feasible, such as "to begin do".)

Frank

--
Frank Heckenbach, frank@xxxxxxxx, http://fjf.gnu.de/
GnuPG and PGP keys: http://fjf.gnu.de/plan (7977168E)
Pascal code, BP CRT bugfix: http://fjf.gnu.de/programs.html
Free GNU Pascal Compiler: http://www.gnu-pascal.de/
.

Relevant Pages

  • Re: C problem which Im having problems with
    ... The old version was held in a single mammoth ... > I've traced the problem to some global char arrays. ... > searching using metacharacter as a search string... ... > compiler hit the tokenCode function, it gave a warning that parameter ...
    (alt.comp.lang.learn.c-cpp)
  • Re: Array of strings
    ... I'd guess this is a compiler ... > artifact of how the thing was coded and how Delphi treats string literals. ... > space each time an assignment was made would be horrendous. ... (Dynamic arrays, anyway; I haven't ...
    (comp.lang.pascal.delphi.misc)
  • Re: Iterable arrays
    ... must have an iterator method that produces an Iterator. ... What are the methods of arrays? ... Special-cased by the compiler. ... For the String[], ...
    (comp.lang.java.programmer)
  • Re: OO programming - illumination? - whoopsie
    ... > represented by a host of loosely related arrays. ... > compiler and the memory allocators. ... A pointer is usually a word. ... organs can be further modeled to include cells and so on and so forth. ...
    (comp.lang.java.programmer)
  • Re: OO programming - illumination? - whoopsie
    ... represented by a host of loosely related arrays. ... compiler and the memory allocators. ... As a matter of fact there is no such thing as a pointer. ... memory that just holds a terminator, which is 0 by convention. ...
    (comp.lang.java.programmer)