[fpc-pascal] Illogical automatic dereferencing

[Jürgen Hestermann]

>> p
> The value of  a pchar.

What do you mean by "value"? The pointer or the character it is pointing 
to? It seems that p sometimes means the first and sometimes the latter.

>> p^
> the char pointed to.

Is this the same as p?

> I don't think you can say anything from pure syntax without bringing in the
> typing. The fact that the pointer type required ^ in the past so that you
> could make the distinction in this case is therefore negiable.

I don't understand what you mean here. If I write a constuct (like "p") 
it should mean the same in all circumstances. Otherwise it's becoming 
tricky when you need to think about the context too when writing code.

>> To put one on top, the meaning is even context dependent (using it in an
>> expression or as a paramater of a function may give it have different
>> meanings).
> True, but that is due to additional conversions in the expression, not the
> strict meaning of the notation.

Again I don't understand what you mean with "additional conversions". If 
I want to access a pointer or its address or the data it is pointing to 
I should have an unambiguous, uniform and different syntax for all these 
3. But this is no longer the case.

>> I am not sure why following the strict logic would generate more work. 
> Because when you are converting, (and then I mean manual or semi-automatic,
> because reliable automatic conversion is hard), then the small errors that
> this leads to can cost you days of debugging work.

Why that? In Turbo Pascal times I often coded complex nested data 
structures with records, arrays and pointers pointing to them. Then it 
often happened that I accidentaly used a pointer where I should have 
used the dereferenced pointer (or vice versa) but the compiler 
immediately raised an error and showed it to me. Now the compiler starts 
beeing smarter than I am and guesses what I could have meant. That's not 
very debugging friendly.

> That bit of code: yes.  However not having these is not an option either,
> since it makes interfacing costly and hard to maintain, which is why these
> features trickled in. And you are incompatible with Delphi and also MUST
> convert there.... (not entirely true, some of them were in FPC first, due to
> its own particular needs)

Regarding arrays and pointers I can't see your problems. If in C a 
pointer is required you can use one in Pascal too. For function 
parameters you can use by reference or by value (to mimic what C does 
with pointers). So where is the problem?

> If it hadn't been for Delphi compatibility, the extensions maybe could be
> limited to a certain mode, or unit type.  (since modes are nowadays global
> per unit, if there was no delphi compatibility, the dialect selection could
> be in the unit declaration)

Yes, Borland was the culprit who introduced all this to Pascal. I was 
realy disappointed about it at that time. But Free Pascal is no longer a 
slave of Borland so could correct their errors.

> I don't think a handful of extensions are that bad. If it bothers you so
> much, submit patches for directives to turn them on/off.

If I would change my code only I would have an island solution. Reading 
code from others (for example Lazarus source code) would still be a 
problem. It is already a problem that no Pascal standard exits anymore. 
Adding yet another variant is not good. I once thought that Pascal was 
superior to other languages because of it's clear and strict concept but 
now there is no longer *the* Pascal language anymore.