[fpc-pascal] Illogical automatic dereferencing

[Marco van de Voort]

In our previous episode, Jürgen Hestermann said:
> > And the criticism about introducing Cisms in FPC/Delphi is also old. In the
> > past I would have joined you, but after a few non-trivial header conversions
> > and library conversions that pretty much died out.
> 
> But why are you then using Pascal at all? I love this language because 
> of its strict logic (which make coding and debugging much easier) but 
> having all these illogical C-style things creeping in makes it less Pascal.

I like Pascal because it makes me more productive.
 
> if you have
> 
> var p : pchar;
> 
> what do the following contructs mean?

(depends on delphi version, in D2009+ it is a pwidechar, before a pansichar)
 
> p

The value of  a pchar.

> p^

the char pointed to.

> @p

The address where the pointer is stored

> p[2]

The 3 third char starting from the address the pointer points to (1 based)

> @p[2]

The adress of the above.
 
> If it were pure Pascal I could immediately tell you but with this 
> C-style notation I am always doubting about the meaning.

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.

> 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.
 
> 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.

> Of course, automatic translation from C to Pascal is getting more 
> difficult, because you then face the drawbacks of C. If you transfer C's 
> flaws into Pascal there is no need for changes. But what are you 
> getting? You get C.

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)

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)

> > In 1.0.x times headers were often "pascalized", but if you have answered
> > several tens of bugreports where people converted a C example and pass a
> > pointer to a formal parameter, you get tired of it. Likewise you also get
> > tired when you need to update some header (or code like zlib,jpeg) and have
> > to guess what the purpose and consequences of some pascallization are.
> 
> And the solution was to introduce the same C design flaws into Pascal so 
> there was no need to change code (other than replacing { by begin and } 
> by end)? Then what is the difference between Pascal and C anymore?

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.