This bevaviour is likely when someone starts with fpc, because the default mode is Free Pascal (-Mfpc).

Wouldn't it be good to give an additional suggestion if the identifyer ist result and the mode is -Mfpc?

For example: Identifier not found "result", may could be resolved with other syntax mode (-M...)

Since this behavior is documented, one should read the documentation first: http://www.freepascal.org/docs-html/ref/refse76.html

Anyway, how could one find that Result is used as function result without reading the docs?

leledumbo wrote

Since this behavior is documented, one should read the documentation first: http://www.freepascal.org/docs-html/ref/refse76.html

There is much documentation spread over many servers.

Anyway, how could one find that Result is used as function result without reading the docs?

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.

Of course now you can say he has to read the documentation, but this you can say nearly to every question for which a solution is documented in the docs.

As I read from your statement your opinion is that my suggestion is completely needless. I know it now, but for the beginners it will be a help to not get demotivated with reading all the docs.

I agree. However I don't know whether a blanket "you're in the wrong mode, lackwit!" error message would be a solution, since it's possible to envisage cases where result is an ordinary variable and should be referenced as such- irrespective of mode.

procedure xxx(var result2: yyy);
begin
   result := zzz

I don't understand that remark: Leledumbo is referring to correct spot in the official FPC documentation.

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.

Perhaps if in Lazarus he could just press F1 when on the result identifier[1]. If in the fpc IDE, presumably there's context sensitive help. That would work for other similar problems, too.

If the user doesn't use an IDE then yes, I think he should go through the documentation manually.

If you feel so strongly about the issue though, why not submit an issue+patch?

[1] However, that doesn't seem to work. See bug
http://bugs.freepascal.org/view.php?id=22754

For people who switch from Delphi or TurboPascal to Freepascal this scenario is very unlikely because the source already compiles errorfree (I hope so).

Also if starting with freepascal your scenario is unlikely (not that I don't see what you want to say).

The message could be a question: "are you in the right syntax-mode?" This is better than leave the beginner alone with reading the docs.

This message is even more a better help for beginners: "are you in the right syntax-mode? only ObjFPC (-MObjfpc) or Delphi (-Mdelphi) mode supports a function result"

But a beginner has to read many documents.
Wouldn't it be better to come to a solution (compiled program) as fast as possible to stay motivated?

I had this thing with lazarus but was not aware of a fast help about this.

If the user doesn't use an IDE then yes, I think he should go through the documentation manually.

A short message would help the user faster than searching for the right document.
Even more a beginner could turn away because of this behaviour and say freepascal is not mature if it does not support a function result.

<snip>
As I said, perhaps best to raise an issue+patch if you feel so strongly about it.

I am not familiar with the compilers soucecode. That will take some time I think. I don't think that it is that difficult to implement.

If the identifyer that was not found is named "result" then a compiler message "are you in the right syntax-mode? only ObjFPC (-MObjfpc) or Delphi (-Mdelphi) mode supports a function result" is shown.

That will help beginners to stay motivated instead of (maybe) searching another language.

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

What's wrong with such a message that is easy to implement and will help beginners to freepascal a lot?

Rainer Stratmann wrote

TP for DOS at least supports a function result (as I remember) thus it is not Delphi only as you mention.

It supports a function result, but it doesn't IIRC treat 'result' as a special identifier. Delphi /has/ to have 'result', since otherwise redefining standard operators would result in something like

operator := (wle: WordLE): word;
begin
{$ifdef ENDIAN_LITTLE }
   Move(wle, result, SizeOf(:=))
..

which is clearly absurd :-)

Rainer Stratmann wrote

I am not familiar with the compilers soucecode. I don't think that it is that difficult to implement.

Those two statements are contradictory. I've previously raised issues related to command-line options and error messages, and had the issues patiently explained to me by Jonas et. al.

In other words, if I wrote the compiler I would know where to implement. So we are at the point where you see my suggestion helpful?

My absurd example wasn't absurd enough :-) Should have read

operator := (wle: WordLE): word;
begin
{$ifdef ENDIAN_LITTLE }
   Move(wle, :=, SizeOf(:=))
.

Rainer Stratmann wrote

TP for DOS at least supports a function result (as I remember) thus it is not Delphi only as you mention.

Turbo Pascal does not support the "result" alias for the function result.

What's wrong with such a message that is easy to implement and will help beginners to freepascal a lot?

We give such a message when someone tries to define a "class" type without having ObjFPC/Delphi mode activated. That is a message that is always correct, because

type
  tsomething = class
  end;

does not and cannot have any other meaning in another compilation mode. As has been pointed out by other people, that is not true for random occurrences of the word "result" in the source code.

Jonas

Even then the message
"are you in the right
syntax-mode? only ObjFPC (-MObjfpc) or Delphi (-Mdelphi) mode supports a function result"
can not be wrong. Added to this that the occurence of the identifier "result" not using in combination with a function result is very unlikely. I think 99,99% has to do with the scenario that I described. And maximum in one of a thousand cases it is the scenario that has been pointed out above.

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

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

Ok so you prefer to let the beginner leave out in the rain. Because he and someone else (more experienced) _could_ mislead a clearly formulated message (are you in the right syntax mode?).

But such an error message would have to come from code that recognised 'result' as a special case, which it is not: in no mode is 'result' either a predefined identifier or a reserved word. Or rather (speculating, and expecting Jonas to correct me :-) 'result' has a special meaning when a function declaration is parsed, but not when the block which forms the function body is compiled.

I'm not denying that an improved error message might be useful. However its implementation might result in far more work than is justified.

Tomas (and Mark) explained with coherent, well written, valid reasoning why implementing this idea of yours would be too much work for too little gain.
Then you go and repeat your initial stance (tinged with an accusatory undertone) without taking into account that reasoning. Strange.

I'd propose you either get stuck in the sources and figure out a patch that covers all corner cases (both already described and any others) ("I don't think that it is that difficult to implement") or... accept the people that posted won't do it.

Also, emphasizing positive aspects/solutions in posts (instead of negative aspects) may lead to a bigger chance of convincing people to do things your way.
It will definitely make for a nicer atmosphere.

Thanks,
Reinier

Jonas Maebe wrote

Turbo Pascal does not support the "result" alias for the function result.

Yup, I can confirm that. I just tested with Turbo Pascal 5.5 :) Wow, that brought back memories.

Graeme.

TP 7.0 also does not support a function result.
I donwloaded it and test it in a DOS Box.
I could swear that it supports it...

TMT Pascal (now Framework Pascal) _does_ support a function result. Although it is not described in the online documentation. http://www.frameworkpascal.com
This userfriendly pascal compiler I used some years.

I read some backup sorcecode made with TMT pascal and see that I make extensive use of the function result variable (because of easy to use and save time when changing the function name). Thus I thought freepascal is not mature when an error like:
'identifier "result" not found' comes up with no further comment.

Rainer Stratmann wrote

TMT Pascal (now Framework Pascal) _does_ support a function result. Although it is not described in the online documentation. http://www.frameworkpascal.com

http://www.frameworkpascal.com/contribs.htm

The first demo program uses already the result function result.

Rainer Stratmann wrote

Thus I thought freepascal is not mature when an error like: 'identifier "result" not found' comes up with no further comment.

'Result' is a Delphi-ism. FPC predates Delphi. FPC is mature in terms of age, mature in terms of stability, and mature in terms of the developers not liking changing established features: sometimes that frustrates almost everybody, but it's something to be lived with.

Reinier Olislagers wrote

On 30-8-2012 18:44, Rainer Stratmann wrote:

[...]

[OT]
Wonder if R.S. can take a hint at least from somebody with same-sounding name :J

L.

Rainer Stratmann wrote

I could swear that it supports it...

I thought the same, and that is why I tried it myself. :) I guess we have been with Object Pascal for too long, and forgot the difference between Pascal and Object Pascal.

Graeme.

How does one error message add to or detract from Delphi compatibility? I could equally point out error messages from the compiler due to its cross-platform nature that Delphi doesn't emit.

Reiner. If you don't like it, then take the sources of the compiler and start your own branch. Deduce how it works- and elsewhere you might see that I'm putting /my/ neck on the line by being critical of the limited extent to which this is documented, so don't think that it's just you fighting the system- and fix what you perceive as a bug. But just be damned sure that your result doesn't break anything, runs all the compiler tests on all platforms, and tracks recent developments.

When you're done, come back with a patch. But until then, go fork >:-)

I did not say that as you can read above.
You can make private mails from me public, but then you must accept my public response.

I could equally point out error messages from the compiler due to its cross-platform nature that Delphi doesn't emit.

Reiner.

Rainer

I did not percive it as a bug.

Hi,

Can this thread please be moved to fpc-other? I think everyone has been able to make their opinion clear on this matter.

Thanks,

Jonas
FPC mailing lists admin.

I am not aware of your having sent me any private emails, and I certainly haven't solicited any: the only mail that legitimately arrives in this account is from the list.

If I'm guilty of making public something that should have remained private then I apologise. But apart from that my sentiment stands: you're criticising the project without being in a position to judge the implications of the changes you're requesting, and on occasion you've accused an individual developer of willfully ignoring your suggestions.

SOP around here is that if you have a bug or suggestion then you raise it in Mantis. If it's a bug then you append example code, and in any case you stand far more chance of having the concern addressed if you're able to contribute a patch.

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:

+1. Since Result is not really special, i.e. it can be declared by user, it would be difficult to detect whether it's user's intention or not.

@Jonas: just a clarification for Mark.

@Mark: The following part you quoted does not seem to have been sent to the mailing list as the corresponding mail from Rainer where you quote from is not in the archive:

Regards,
Sven

Il 31/08/2012 13:48, leledumbo ha scritto:

Treating just Result as a special case might not be worth while.

However a more general feature could perhaps be useful: as the compiler knows all the keywords of all its modes, if an unresolved identifier happens to match a keyword of a different mode, a warning, sort of "wrong mode?" could be added. The overhead should be negligible, because it would occur only in case of unresolved identifier, and after a few of them compilation is stopped in any case.

Giuliano

1. "Result" is never a keyword.

2. There are context sensitive keywords that are not considered as global keywords in any mode (e.g. "read" and "write" of properties) and thus only the part that parses them (in the example the parser for properties) "knows" that it should consider these identifiers as keywords.

Regards,
Sven

Il 02/09/2012 18:26, Sven Barth ha scritto:

Too bad :-)

Giuliano