On Thu, August 30, 2012 17:14, Rainer Stratmann wrote:
> Am Thursday 30 August 2012 16:50:30 schrieb Tomas Hajny:
>> > The scenario occures when someone starts freepascal as I already
>> > documented in
>> > my first E-Mail.
>> >
>> > When someone wants to compile a TurboPascal or Delphi program with
>> > freepascal.
>> > Then he already knows that result is a function result, but freepascal
>> > gives
>> > an error about this.
>>
>> Identifier Result was not known/supported as function result in TP/BP,
>> i.e. your statement applies to Delphi only. Still, people with Delphi
>> background are obviously more likely to come across FPC nowadays, but
>> these people usually need $MODE DELPHI anyway due to many other things
>> they are used to and I miss to see how this one particular case improves
>> the overall situation for them. On the other hand, pointing out all
>> differences among the different modes by similar compiler messages is
>> fairly likely to require considerable effort.
>>
>> Tomas
>
> It is not about pointing out all differences.
>
> It is _simply_ that what I guess occures often when a beginner starts with
> freepascal. The realization of this message is easy I think. TP for DOS at
> least supports a function result (as I remember) thus it is not Delphi
> only as you mention.
I tried it with TP 7.0 before my post to make sure that my memory served
well. I'm not aware of any such function in TP/BP either, at least not in
unit System (I checked too, just in case ;-) ).
> Even if it is Delphi only the programmer who switched to
> freepascal sees the message 'identifier "result" not found' and is forced
> to
> study the documentation (which he already has to do much when starting
> with
> setting up the whole fpc environment). I have this thought that freepascal
> is
> not mature when I saw this the first time. And if there is a _simple_
> message
> like described in other mails then the most obscurities are eliminated. In
> TP/BP there was not a syntax mode as far as I remember (or preconfigured
> one). The IDE worked out of the box!
Yes, of course. FPC works out of the box too for supported syntax, equally
to TP/BP (and you even have more options to choose from).
> What's wrong with such a message that is easy to implement and will help
> beginners to freepascal a lot?
I'm afraid that this leads nowhere. I question your assumption that
"Result" is specifically more important than the other incompatibilities
among different modes (i.e. your statement that it "will help...a lot"). I
do not say that it is wrong to be more helpful in error messages, but
rather that your proposal tries to "fix" a very small fragment of
something much more general and moreover that the proposed message may be
very easily misleading as already demonstrated by Mark. Yet other cases
might not be detected by the compiler at all:
---
var
Result: boolean;
function F: boolean;
begin
F := false;
{some longer section of code may appear here}
Result := true;
end;
begin
WriteLn (F);
WriteLn (Result);
end.
===
This code is valid for both fpc and objfpc modes, but the output is
different. Should the compiler try to detect it somehow? It could point
it out by providing a hint about Result having some special meaning in
other modes but should it?
I could equally ask why TP 7.0 errors out on:
---
var
S: string;
begin
S := 3.1415926;
end.
===
with:
---
TEST.PAS(4): Error 26: Type mismatch.
S := 3.1415926;
^
===
instead of the much friendlier message
---
test.pas(4,7) Error: Incompatible types: got "Extended" expected
"ShortString"
===
provided by FPC. I'd assume that type incompatibilities are a much more
common issue for beginners (and not only them). Should FPC suggest the
user to add quotes around '3.1415926' or to use some other variable or to
call some conversion procedure like Str or ...? No, it should not because
it doesn't know what the user intended to do.
Tomas
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
