Hello,

Theoretically speaking, I'm all for type checking; and for programming discipline in general. But in practice I never get type errors. What the compiler complains about is all kinds of plain grammatical errors:
* typos
* missing ';' (many)
* wrong number of 'end'
* name error
* signature error (forgot to change proc/func declaration after editing definition)

But errors like the folllowing, never:
trial.pas(14,7) Error: Incompatible types: got "Extended" expected "LongInt"
[source:
program trial;
var
	n : Integer;
begin
	n := 1.1;
end.
]

The only kind of type error I get is when I forget to "cast back" a pointer from a pointer collection such as TFPList.

So, a few questions:
* Do you get type errors?
(playing the devil's advocate:)
* What is type checking _actually_ useful for?
* What about a compiler without type-checking?

Denis
________________________________

vit esse estrany ☣

spir.wikidot.com

spir :

Theoretically speaking, I'm all for type checking; and for programming discipline in general. But in practice I never get type errors.

Then you are either a genius or you are using not enough types. ;)

So, a few questions: * Do you get type errors?

Occasionally, yes.

(playing the devil's advocate:) * What is type checking _actually_ useful for?

Type checking only does not help anything. You need to make use of types to actually benefit from such checks. If everything in your program is either integer or float, then the probability of catching errors through the type checking system is rather low indeed.

* What about a compiler without type-checking?

There are already too many of them. :-P

Vinzent.

e:)

* What is type checking _actually_ useful for?

I would be lost without type checking,
especially when using sophisticated data structures like pointers to arrays of records (which again
contain pointers to other complex structures).
An example:

type  ArrayType = array[1..10] of SomeType;
      PointType = ^ArrayType;
var   X : PointType;
      Y : SomeType;

What happens if you forget a dereferencing ^ in an expression like this:

Y := X[7]

where it should have been

Y := X^[7]

What does the compiler do without type checking
in the first case? Does it access X as if it
was an array (of what element type/size?).

It often happens that I change a type into a
pointer to that type. Then I expect that the
compiler shows me all places where I now get
a syntax error so that I can change the code
instead of having the compiler "guessing"
some meaning (that I may not have intended).

I also often change a string type into an integer
and vice versa. That implies a lot of code changes. Again with type checking I can lean back and
rely on that the compiler will show me all places
where these changes are needed.

For sure!
Now, it is easy for the compiler to guess such cases. Some languages perform automagic deferencing of pointers to structured types (record/object, array), meaning eg p.x
is interpreted as
p^.x
and
p[i]
is interpreted as
p^[i]
There is no ambiguity since the pointer nature of p is known by the compiler before such lookups can be parsed. Oberon -- also designed by Wirth and thus not to be considered as weakly secured ;-) -- works that way. Also note that all languages holding implicitely referenced object types can only work that way... including fp for Delphi-like OO (and all dynamic languages like python or Lua).

Nice use of the compiler ;-) But only needed since implicite dereferencing is not a feature of the language.

Denis
________________________________

vit esse estrany ☣

spir.wikidot.com

In our previous episode, spir said:

And in the case of ppointer?

Oberon doesn't have that case afaik.

Now, it is easy for the compiler to guess such cases.

I don't want the compiler to "guess" at all.

Yes, it has even become part of Free Pascal (AnsiStrings, Open Arrays). Still I don't like it. And it was only an example for the benefit of type checking when using pointers heavily. And wasn't there also the possiblity of pointer arithmetic...?

There is no ambiguity since the pointer nature of p is known by the compiler before such lookups can be parsed.

It's not only a question of ambiguity. I may not have fully understood you question but how would you *avoid* type checking? If you assign an integer to a set variable the compiler should complain, shouldn't it? If no type checking is done then simply only bytes are moved? That's assembler...

Nice use of the compiler ;-) But only needed since implicite dereferencing is not a feature of the language.

No. If you need access to the pointers themselves you cannot have implicit derefferencing. That's the general problem with AnsiStrings and Open Arrays already. It becomes a real problem when you create your own data types which make use of pointers heavily. Then you *need* access to the pointers themself *and* to the data they point to. This would be impossible with automatic derefferencing.