Hi, all!

I used to work in Pascal (Delphi/fpc) for 10 years, and later had to go to C++ (because of my day job). Now, I'm back to fpc, and one thing I really miss is ability to have semicolon before else.

So, here's (attached) patch for fpc that makes it possible. The only problematic place for this syntax change is inside case statement, when last branch is single if statement, for example:

case p of
'1': do_1;
'2' if (q > 0) then do_2;
else do_3;
end;

It is not clear if else should be part of branch '2' (part of if statement), or else branch for case. Fortunately, there is also 'otherwise' (I bet only few out there know about it, I've discovered it this night!) which can be used instead of else inside case, which can be used to clarify intent, so that default behavior could be to interpret else as part of if statement.

Note that attached patch has lots of bad points:
- besides compiling fpc itself with this change (and changing some else-s to otherwise-s), as well as some of my projects, I haven't officially tested it
- from design point of view, it's very 'dirty' (I mess with scanner internal state from statement parser - ouch, that hurts!)
- because of possible problems, else as part of case should be deprecated, or discouraged, or there should at least be warning if last branch before else is single if statement
- this patch only applies to else branch of if statement, not one inside case (because, as stated before, you can use keyword 'otherwise' inside case)
- I'm pretty sure there are still some else-s inside case-s inside compiler/rtl/fcl which introduce bugs, I just didn't hit those places; the proper solution here is to either add begin/end, or change code to use 'otherwise'

Anyway, as far as I can see - it works!

Hope someone will find it useful. Or not :-)

Regards,
Aleksa

On Tue, 26 Jan 2010 01:08:45 +0100, Aleksa Todorovic wrote about [fpc-devel] Semicolon before else:

[snip]

A quick examination of Jensen & Wirth's original Pascal grammar will tell you how that should be parsed: in Pascal there is *never* a semi-colon between the "then" clause and the "else" in an "if" statement.

I must agree with David. The idea of the extra semi-colon just adds confusion and no extra value.

Example where 'do_3 is part of the case statement:
  case p of
    '1': do_1;
    '2' if (q > 0) then do_2;
    else do_3;
  end;
Example where 'do_3' is part of the '2' if/else statement:
  case p of
    '1': do_1;
    '2' if (q > 0) then do_2
        else do_3;
  end;

Syntax and understanding is as clear as rain. Adding extra semi-colon, as you suggested, is not.

As for the 'otherwise' syntax. You are correct, I have never heard or seen it before. :-) But it is documented in the FPC Language Reference section 10.2.2.

Regards,
- Graeme -

Op Tue, 26 Jan 2010, schreef Graeme Geldenhuys:

David W Noon wrote: Syntax and understanding is as clear as rain. Adding extra semi-colon, as you suggested, is not.

Indeed, it would be undesired to accept that semicolon. What makes me uncomfortable is that he went to the trouble of modifying the compiler for it. We should encourage that.

As for the 'otherwise' syntax. You are correct, I have never heard or seen it before. :-) But it is documented in the FPC Language Reference section 10.2.2.

"Otherwise" is used in some Pascal dialects instead of "else". This is where it comes from.

Daniël

Daniël Mantione wrote

Indeed, it would be undesired to accept that semicolon. What makes me uncomfortable is that he went to the trouble of modifying the compiler for it. We should encourage that.

I know, it is impressive that somebody went through all that trouble in modifying the compiler, but I think it would be wise for anybody in the future, to first mention your issues and ideas here, before simply implementing it.

Unless there is some command line parameter that can toggle that behaviour (like what was done with '-Sc' C style operator support), then his work would not have been in vain. In this case, I would suggest by default that that syntax is not allowed. The command line parameter will enable it.

Regards,
- Graeme -

Thank you for your responses.

Agree. My primary intention was not to change official language, but to try to make a change which will help me in my work. I just shared it with others.

Note that I fully understand how serious this change is. First, it moves away FPC from the land of Separator to the land of Terminators. Second, the grammar/parser is not LL(1) anymore (which is enough to reject this change in the first place). Third (as Daniel said), it requires change of compiler itself (else->otherwise). And so on, and so on...

So, if this patch is useful to someone, then it's great; else (if it's not), great again ;-)

Aleksa Todorovic wrote

Agree. My primary intention was not to change official language, but to try to make a change which will help me in my work. I just shared it with others.

But in that case what's needed is not a simple change to this one case but an option to accept Modula-2 style syntax where you've got if...then...end; etc. hence eliminating the "dangling else" problem.

There's also the issue that Turbo Pascal was very strict in rejecting ; before else in certain circumstances such as in a case statement: it was reported as a syntax error even if it could be parsed by other compilers. Enhancing the language is all very well, but anything which introduces a subtle incompatibility with one of the most popular Pascal implementations is probably not a good idea.

So, if this patch is useful to someone, then it's great; else (if it's not), great again ;-)

But the more people who build up the skills to understand the compiler's internals the better :-)

In our previous episode, Mark Morgan Lloyd said:

Agree fully, that's how Wirth solved it, and I like it still best.

Indeed, that would be far better solution. But, I wonder how many people out there would be interested in having support for Modula2 syntax inside fpc...?

I believe `otherwise' was in VAX/VMS Pascal in the early 80's, which, I must say, was a Pascal implementation way ahead of its time, including the passing of dynamic arrays, and much more.

Regards, Arnstein.

In our previous episode, Aleksa Todorovic said:

I don't think this is worth fixing in the Pascal
compatibility simply weights more heavily.

But I've been dreaming of a M2 mode in FPC for quite some time. It would fit rather nicely.

Hi,

I actually suggested a similar change for Delphi years ago. Its value and benefit is obvious: when adding ELSE to and existing IF statement.

  if a then
    DoSomething;

must have a semicolon, but

  if a then
    DoSomething
  else
    DoSomethingElse;

must NOT have a semicolon. It is irritating when you add ELSE to an existing IF statement and try to compile.
Or, am I the only person who has tried to do that?

I understand it brings problems with "CASE" and also with nested if statements.

Object Pascal is otherwise a nice language but there are few annoying syntax details that other languages have solved better. Three such cases pop into my mind:

1. This semicolon / no semicolon irritation.
2. Const array syntax. You should not need to define the upper bound. This was discusses in Lazarus mail list.
3. Circular references. This is the worst and it really makes this language less popular for big projects. There was another mail thread about it.

Regards,
Juha Manninen

Never use "then .. else" naked but instead "then begin ... end else begin ... end" with appropriate indentation (I prefer "end else begin" alone in a single line, but this is a matter of taste :) ;

-Michael

Daniël Mantione wrote

"Otherwise" is used in some Pascal dialects instead of "else". This is where it comes from.

Delphi does not seem to accept it...

-Michael

Daniël Mantione wrote

We should encourage that.

Maybe from his work he could derive an "acceptable" patch that issues an "ambiguity" warning just if a Semicolon decides between two syntactically correct code variants with different behavior.

-Michael

Never use "then .. else" naked but instead "then begin ... end else begin ... end" with appropriate indentation (I prefer "end else begin" alone in a single line, but this is a matter of taste :) ;

I also do that sometimes just to avoid the semicolon problem, even if there is only one command between "begin" and "end".

Juha Manninen

Not really, the difference is not so obvious. Maybe there should be warning for situations like this in all Pascal modes? To get rid of it, on would have to wrap if statement with begin/end or add another case-branch before case-else which is not single if statement? Or just ignore the warning...

An "acceptable" solution would need several things:
- new -S option on command line weather to accept this syntax modification (-SE ?)
- scanner improvement (it should be scanner who stores last scanned token with all associated info) - this is, actually the most problematic part of solution
- bunch of test-cases
- some free time to implement it
- lot of good will to accept it :-)

Graeme Geldenhuys wrote

Example where 'do_3 is part of the case statement:

[...snip...]

Example where 'do_3' is part of the '2' if/else statement:

[...snip...]

Oops, in both examples I forgot the semi-colon after the '2' in the case statement. Copy and Paste is evil. :)

Regards,
- Graeme -

Sometimes it's good to write some code first. That way you know better what you're talking about when you start discussing it. ;)

Joost.

I think a number of us are ex-M2 programmers :-) The one thing that does occur to me which could /possibly/ justify an extension of the parser is that the only structures in Delphi/FPC that insist on an extra begin-end around multiple statements are those that were in the original J&W Pascal. In particular the else...end in a case statement was added (by Turbo?) followed later by try...finally...end and try...except...end.

Being able to say that all control and data structures had a uniform format terminated by an end with neither a dangling-else problem nor ambiguities depending on whether somebody used ; as a separator or a terminator could be attractive.

Graeme Geldenhuys wrote

As for the 'otherwise' syntax. You are correct, I have never heard or seen it before. :-) But it is documented in the FPC Language Reference section 10.2.2.

On more probably less known reserved identifier is FAIL. You can use it only inside constructor to indicate that object creation should actually fail and retur nil - meaning that you don't need some factory or creation helper function for those situations. Pretty useful, isn't it? :-)

I'm trying to solve that one :-) So, here's an updated patch with several improvements:
- parser now only uses some additional info from scanner, it doesn't do any modification to scanner internals
- full backward compatibility: problematic else inside case is correctly recognized (weather it is part of last if statement or part of case, including nested if/else-s)
- modified fpc can successfully recompile trunk versions of fpc and lazarus (as well as projects I work on) and everything seems to work fine
- there is also test program, but it uses ordinary Writeln-s, still need to see how convert that to true fpc test

Due to deadlines I have these days, I wont have time to work more on this. After that, if there is good will to accept this patch, I will gladly take some time to make tests and do any modifications needed.

If not, there is another thing I badly need - generics of records, so I'll try to make them usable (before, as Florian said in ticket we "bite the bullet and support methods and operators inside records :/").

Regards,
Aleksa

- full backward compatibility: problematic else inside case is correctly recognized (weather it is part of last if statement or part of case, including nested if/else-s)

Impressive!
I would be happy with that syntax change. However I understood all FPC authors were not as happy with such change.

How does your patch handle this? :

  if a then
    if b then
     DoSomething;
   else
     DoOtherThing;

Regards,
Juha Manninen

Syntax error....

else is handled as part of "if b then" -> the closest preceeding if:

program test3;
var
  x: Integer;
begin
  x := 1;
  if x < 2 then
    if x > 0 then
      Writeln('x=1');
    else
      Writeln('x=0');
  Writeln('---');
end.

D:\alexa\dev\fpc\test\if>pp.exe
@d:\dev\fpc\fpc\bin\bin\i386-win32\fpc.cfg -vV test3.pas Free Pascal Compiler version 2.5.1 [2010/01/28] for i386 Copyright (c) 1993-2009 by Florian Klaempfl
Target OS: Win32 for i386
Compiling test3.pas
Linking test3.exe
13 lines compiled, 1.4 sec , 26032 bytes code, 1560 bytes data

D:\alexa\dev\fpc\test\if>test3.exe
x=1
---

That is so confusing... if the major issue is that if you wanted to add more lines before of after the else, then simply wrap the code with begin..end blocks. If you think that it is too much typing, use a typing tutor to improve you typing skills or use a decent editor that can automatically add those begin/end blocks for you (normally called "code templates").

Non-confusing end result looks like this:

  if a then
  begin
    DoSomething;
  end
  else
  begin
    DoOtherThing;
  end;

or

  if a then
  begin
    DoSomething;
  end
  else begin
    DoOtherThing;
  end;

Lets take Lazarus IDE as an example of a good editor: USAGE:
* type the first few letters and then press Ctrl+J

ifb - if statement
b - begin end
be - begin end else begin end
bg - begin end
ifb - if statement with begin end
ifeb - if then else with begin end blocks
ife - if then (no begin/end) else (no begin/end)

And these are just the begin/end and if statement templates. There are many, many other templates too. So your "solution" just seems like to much work modifying the compiler and the end result is code the developer cannot understand or finds very confusing.

But then it's like you said: It's your patch, use it or don't. :)

Regards,
- Graeme -

I was going to write that's not backward compatible, but it doesn't actually compile with current FPC. I remembered now ELSE would be tied to the first IF. Anyway, there are some weird cases when it's difficult to tell which IF the ELSE belongs to. Those are very rare and then one really should use BEGIN END blocks anyway.

So, if this change is backward compatible then it should absolutely be accepted in FPC.

For Graeme and others: the problem is not the amount of typing. The problem is that you can easily forget this semicolon when you for example add ELSE to an existing IF. First there had to be a semicolon and then there must not be semicolon... Non-intuitive.
So, the goal is to make the language more intuitive and programmer-friendly.

The compiler can deal with complicated things. It could easily understand the semicolon (as we can see with this patch). Instead giving an error feels stupid. It is like with the "const array" syntax. The compiler essentially says:
"Hey you stupid programmer, you left a semicolon there. I easily understand what your code means but still you must change it yourself."

Ok, it is a small thing but still, this language is otherwise clean and intuitive.
Using BEGIN END blocks always solves the problem but they are not used always.

Regards,
Juha Manninen

Aleksa Todorovic wrote

else is handled as part of "if b then" -> the closest preceeding if:

This would break almost all my code.

Juha Manninen wrote

For Graeme and others: the problem is not the amount of typing. The problem is that you can easily forget this semicolon

It's not like you have to drop off your punch cards and come back tomorrow afternoon, is it? I usually don't even have time to take a -sip- of coffee before the compiler's done finding my mistakes, let alone getting up to go chat with the other developers for a couple of minutes. I sometimes miss the days of

What are you doing? Get to work.
Compiling.
Oh, ok.

when you for example add ELSE to an existing IF. First there had to be a semicolon and then there must not be semicolon... Non-intuitive.

Wait, what? It's absolutely intuitive. To use a bad analogy, there had to be a semicolon because you were at the end of the "sentence". When you add the 'else foo' part to that sentence, it's going between the words that were already there and the semicolon that was already there because it's part of that same sentence. It's just like you're adding a ", and then more stuff" to an english language sentence.

So, the goal is to make the language more intuitive and programmer-friendly.

But above that you wrote

Anyway, there are some weird cases when it's difficult to tell which IF the ELSE belongs to.

That's neither intuitive nor friendly to me. But if it works for you and makes your programming better, then I'm glad you came up with it.

Best regards,
Pete C.

Hm... it shouldn't. As far as I tested it, it correctly handles all possible situations. If it doesn't take you much time, can you send me some code which would break, so I can test it?

As well as both

if a then
  DoSomething
else
  DoOtherThing;

and

if a then
  DoSomething;
else
  DoOtherThing;

At least to me they are :-)

But then it's like you said: It's your patch, use it or don't. :)

+1 ;-)

What are you doing? Get to work. Compiling. Oh, ok.

Right, It was a forced social break with C compilers on old computers. When you were really in a creative mood then it ate lots of your time and energy. When the compiler finished your idea was maybe gone and you had to catch up with it again.
Then I got spoiled with Delphi. Lazarus / FPC is little slower but still fast enough.

My idea here was that always if there are nested IFs and some ambiguity, one should use BEGIN END blocks.
In simple cases the compiler could accept the semicolon (but also accept the old syntax without semicolon as the proposed patch does). That would be friendly.

I didn't come up with the patch, it was Aleksa Todorovic. BTW, why doesn't the example code compile in current FPC? I remember such code compiled in Delphi but I am not sure and I don't have Delphi now to check.

Anyway, this is a rather small thing. Most challenges in programming are somewhere else than in the use of a semicolon.

Regards,
Juha Manninen

That's not the issue. The issue is that this is a fundamental syntax change, it has the capability of introducing subtle errors, and if it screws one person's code up such that he has to spend hours or days tracking down a bug in something that used to work then it's done the FPC and Lazarus projects significant damage.

It might well be useful as an optional feature, but under no circumstances enabled by default.

Juha Manninen wrote

BTW, why doesn't the example code compile in current FPC? I remember such code compiled in Delphi but I am not sure and I don't have Delphi now to check.

Because FPC does not support semicolon before else :-)

Because FPC does not support semicolon before else :-)

Ok, I remembered it connects to the first IF when there is semicolon. Apparently I remembered wrong...

It means there is no ambiguity and the patch can be applied without breaking any code.
Or, is there some detail I have missed?

Juha Manninen

It breaks the behavious of case:

case b of
   1 : something;
   2 : If a then
        DoSomethingElse;
else
   DoElse
end;

As it is now, b=2 and a=False will result in no code executed.

After the patch, B=2 and a=False will result in DoElse.

So _if_ this patch is to be applied, then it must be with an appropriate -S command-line switch.

Personally, I don't see the adavantage of this patch.

I don't even understand why people see the current behaviour as problematic. The syntax is unambiguous. You must type your code correct. The if then else statement is no exception to this rule.

One might as well ask that in written language, in some cases ? might be written as ! because it uses less ink.
Go and propose that in a linguistic conference, see where it gets you...

Michael.

Juha Manninen wrote

It means there is no ambiguity and the patch can be applied without breaking any code. Or, is there some detail I have missed?

I have not found any problems, but since this is serious syntax change, I cannot guarantee it.

Have you actually tried it? I've tested those cases and they should work.

So _if_ this patch is to be applied, then it must be with an appropriate -S command-line switch.

Absolutely! But in the first instance, we need to choose if this is actually going to be part of FPC or not.

This "feature" is so unclean and so poorly informed about WHY the ; is a part of the language.
First of all, Pascal is not a line based language. The ; is used as a terminator for a certain part of code, not as a terminator for a blockstatement.
Mixing these three concepts introduces ambiguity.
The ; implies a break, i.e. do not continue the evaluation of that part of the code. Or, like in natural language, whatever comes after it has no direct bearing for its meaning.
It is much like natural language. The ; should not be there if the code is ment to be read as a single sentence. This is pure logical. I hope this "patch" will never make it into production. It is ill informed.

In our previous episode, Aleksa Todorovic said:

Absolutely! But in the first instance, we need to choose if this is actually going to be part of FPC or not.

I don't really see a need for this. Some languages are terminator, some are separator. We are also not Basic in that we try to disambiguate every possible syntax.

It is just a risk without real benefit attached to it, so I'm against.

Then in your patch, how do you distinguish between the else belonging to the case statement and the else belonging to the if ?

Since if I followed this thread correctly, the following is allowed:

   if a then DoSomething; else DoSomethingElse;

So we have an "old style" case statement:

case foo of
   1: DoOne;
   2: if a then DoA;
else
   DoElse;
end;

in this case it is clear, the else belongs to the case.

Now with your patch

case foo of
   1: DoOne;
   2: if a then DoA;
else
   DoElse;
end;
should it be read as
   2: if a then DoA; else DoElse;

or
case
....
else

     DoElse;

???

Marc

+1

To Be brutally honest - +1 for me too. This is very much a solution in search of a problem. If I were looking for any C/C++/C# style features to be added to the language, I would look at the following in no particular order of importance:

1) ++/-- operators
2) for loop
3) single character block statement (e.g., C braces, but maybe another character..)

I also like the idea of declaring variables part way through methods and also the way Java/C# declare methods inline in the class.

None of these I want badly enough to push for them.. indeed some may already be implemented.

When compiler hits 'end' inside 'case', it analyzes syntax tree created for the last branch, and checks if there was semicolon before last else or not (which is clear sign if that else is part of if statement or case).

Hi.

Your explanation is correct but my approach is more pragmatic and less philosophical.
There are some cases already where you can use a semicolon or leave it out. Like :

begin
  if a > 100 then
    DoThing1
  else if a > 50 then
    DoThing2
  else if a > 10 then
    DoThing3
  else
    DoThing4
end

You don't need a semicolon after the last DoThing4 because it is followed by END. That is handy when you need to change order and copy/paste those lines, and none of them has semicolon.
However :

begin
  if a > 100 then
    DoThing1
  else if a > 50 then
    DoThing2
  else if a > 10 then
    DoThing3
  else
    DoThing4;
  FinalAction;
end

Now you needed the semicolon.
Why not allow this, for pragmatic reasons:

begin
  if a > 100 then
    DoThing1;
  else if a > 50 then
    DoThing2;
  else if a > 10 then
    DoThing3;
  else
    DoThing4;
  FinalAction;
end

You can already add semicolons for example after END even they are not required.

This has the same spirit as Perl's array syntax which allows a comma also after the last item. It is handy when reordering or adding items. It may be wrong philosophically or technically (or something) but it works and makes things easier.
(This would be another improvement for Pascal const array syntax, too, but let's not go there now. It need its own thread.)

Regards,
Juha Manninen

+1
why should pascal care about C legacy?

thanks,
dmitry

In our previous episode, dmitry boyarintsev said:

Depends. I do see a minor point for e.g. ++ and --, since I have been bitten by that when translating e.g. compression code (paszlib, lz77) when these are used in complex nested loops.

But this is IMHO not a real risk with the ; thing. (and it is way to intrusive)

So this feature is inconsistent ?

Imagine I've a case like:

  case Foo of
    1 : DoOne;
    2 : If a then DoA; else DoNotA;
    3 : DoThree;
  end;

Now, due to changed requirements, 1 and 3 shout do the same, so I change the case into:

  case Foo of
    1,3 : DoOneAndThree;
    2 : If a then DoA; else DoNotA;
  end;

This will affect the meaning of 2 too, without noticing...

No thank you.

Marc

+1

To Be brutally honest - +1 for me too. This is very much a solution in search of a problem. If I were looking for any C/C++/C# style features to be added to the language, I would look at the following in no particular order of importance:

If we want C style features we should code in C and not in pascal.

Marc

If we're talking about fundamental changes to the language, how about introducing start...finally...end as an alternative to try...finally...end so the type of block can be distinguished at the top rather than half way down?

Marc Weustink wrote

So this feature is inconsistent ?

+1

Excellent example and perfectly showing where the new behaviour would break existing code without notice. I vote against this feature too, purely because it is inconsistent in behaviour.

Object Pascal is about simple easy to read and understand code, it doesn't need such inconsistent and confusing features. The current syntax is clear as rain and doesn't cause confusion. Adding or removing a simple ; character where needed is not ,
- Graeme -

Excellent example and perfectly showing where the new behaviour would break existing code without notice. I vote against this feature too, purely because it is inconsistent in behaviour.

The original inconsistency is that ELSE is reused in CASE statement. If it used OTHERWISE or something and ELSE was dedicated to IF then there would be no problem.
But yes, I understand that is how the language is.

Object Pascal is about simple easy to read and understand code, it doesn't need such inconsistent and confusing features. The current syntax is clear as rain and doesn't cause confusion. Adding or removing a simple ; character where needed is not confusion but little irritation sometimes. Adding or removing ';' is no

effort when you remember to do it.

Now when I think of it, the new FPC language modes can solve many such problems. I understood there are Modula2 and Objective-C modes. And they can use the same compiled units and libraries between languages, or how. (?) That is cool! The same benefit Parrot or .NET have but with compiled languages.
GCC supports many languages, too, but they can't use each others' libraries so it is quite useless.

Regards,
Juha

Juha Manninen wrote

Anyway, this is a rather small thing. Most challenges in programming are somewhere else than in the use of a semicolon.

This is so, so wrong. It is not a small have redefined the language is a subtle but significant way.

I fear if the patch is accepted into the mainstream FPC compiler people will forget about it and code using the new syntax will its way into the general libraries. I vote to keep the patch OUT of the mainstream FPC compiler, even as an option. Let the people who want it patch their personal copies.

Just to show you I'm really considering this stuff: I like the enhancement to have the compiler count enumerated values and not force to developer to do it. But I don't like the semicolon change.

Juha Manninen wrote

Now when I think of it, the new FPC language modes can solve many such problems. I understood there are Modula2 and Objective-C modes.

There is no Modula2 mode. There is an Objective-Pascal mode, but no Objective-C mode.

And they can use the same compiled units and libraries between languages, or how. (?)

Units compiled in different dialects can indeed be mixed in the same program.

That is cool! The same benefit Parrot or .NET have but with compiled languages.

No, it is much more limited. And of course, .NET/CIL can also be statically compiled to machine code.

GCC supports many languages, too, but they can't use each others' libraries so it is quite useless.

You can perfectly use a library compiled with gcc in a gpc-compiled program. You just have to translate the headers. Just like in case of e.g. Objective-Pascal, you have to translate the Objective-C headers to Objective-Pascal before you can use the library/framework for which these headers have been written.

Jonas

There is no Modula2 mode. There is an Objective-Pascal mode, but no Objective-C mode.

Sorry, yes. I knew it was Objective-Pascal, used in Mac, but I wrote it wrong. I remember reading about Modula2 mode but it must have been just an idea.

Ok... which way? They can mix and interact in the same program as you told.

And of course, .NET/CIL can also be statically compiled to machine code.

Ok.

You can perfectly use a library compiled with gcc in a gpc-compiled program. You just have to translate the headers

Right. That is the limitation. And the object oriented classes (in C++) you can't really translate except for making them flat functions.

Regards,
Juha Manninen

In our previous episode, Juha Manninen said:

Yes, it is my running gag what I would do if I won the lottery.

Indeed.

In case of FPC it's just a few handful of dialects that are supported by a single compiler. A generic intermediate format can facilitate easily combining the output of multiple completely different tools, the creation/use of generic instrumentation/analysis/verification tools that work on this format, the choice between static and dynamic compilation (or a mix), annotations of the generated code in a standardised way for use by tools that will process it later, ...

> You can perfectly use a library compiled with gcc in a gpc-compiled > program. You just have to translate the headers Right. That is the limitation.

As I said, the same limitation goes for FPC: if you want to use a library written in Objective-C from Objective-Pascal, you also have to translate the headers.

And the object oriented classes (in C++) you can't really translate except for making them flat functions.

GPC also supports several different Pascal dialects (ISO Standard, ISO Extended, Mac-style Pascal, Turbo Pascal, GPC-specific, ...), GCC supports several different C standards (K&R, C89, C99, ...), G++ supports different C++ standards, ... And as far as I know, you can also combine compiled source files written in different language variants in the same final binary.

Jonas

In our previous episode, Jonas Maebe said:

>> program. You just have to translate the headers > > Right. That is the limitation.

(well more a difference)

As I said, the same limitation goes for FPC: if you want to use a library written in Objective-C from Objective-Pascal, you also have to translate the headers.

I think Juha means that gcc collection must define headers for different gcc based languages to interoperate, while FPC's dialect modes don't.

I'd like to hear your opinion on what exactly causes this too. I thought about it, and would roughly say:

1) the FPC cg accepts roughly a kind of superset of pascal dialects, and the dialect modes map onto it.
2) the fact that precompiled units roughly are a binary representation of the header converted in this superset?

while
1) gcc's GIMPLE is lower level (not a common superset of dialects/languages)
2) gcc derivatives don't store their haeders in a binary representation in such superset.

Op Fri, 29 Jan 2010, schreef Jonas Maebe:

GCC supports several different C standards (K&R, C89, C99, ...), G++ supports different C++ standards, ... And as far as I know, you can also combine compiled source files written in different language variants in the same final binary.

Here you do not do justice to your own technology. GCC can indeed support several different standards, but mixing them is complicated because header files need to have syntax compatible with the current selected standard. Further, the coupling is only achieved at the linker stage, which means both dialects must produce 100% binary interoperable code, while FPC fully understands differences at the compiler stage, i.e. in a mode where "integer" is 32-bit, it will perfectly work with datastructues defined in a mode where "integer" is 16-bit.

Daniël

I think the binary representation is unrelated. It can also work if C headers contain a #pragma that indicates the language mode they are written in (and the C file that includes them contains another #pragma, or the mode setting in the header is preceded by a "push" and followed by a "pop" of the current/default language mode). I don't know whether GCC supports this though.

Jonas

Marco van de Voort wrote

Depends. I do see a minor point for e.g. ++ and --, since I have been bitten by that when translating e.g. compression code (paszlib, lz77) when these are used in complex nested loops.

Hopefully, it would be easy to implement it "manually":

function PreInc(var value: T; Delta: Integer = 1): T;
function PostInc(var value: T; Delta: Integer = 1): T;
function PreDec(var value: T; Delta: Integer = 1): T;
function PostDec(var value: T; Delta: Integer = 1): T;

(with obvious implementation for any T supporting operator +/-). One could even think of something like:

function generic<T> PreInc(var value: T; Delta: Integer = 1): T;
function generic<T> PostInc(var value: T; Delta: Integer = 1): T;
function generic<T> PreDec(var value: T; Delta: Integer = 1): T;
function generic<T> PostDec(var value: T; Delta: Integer = 1): T;

But... let's don't go there, generics are still not fully functional in their present form.

The post-increment is only evaluated after the entire expression has been evaluated in C (and even that simplistic description is probably wrong if you put it next to what the standard actually says). E.g.:

   int i, j;
   i = 0;
   j = i++ + i++;

After this, i=2 and j=0 (rather than 1).

Anyway, pre/post-increment operators are not a good idea. They are also discouraged by many C programmers these days (except in for- statements or single line statements equivalent to inc(i) in Pascal), because it can sometimes be very hard to understand the side effects in complex expressions (different C compilers can give different results with some expressions, because the C standard gives compilers quite some freedom regarding the evaluation order).

Jonas

Ahhh, yes - I answered too quickly.

29.01.2010 14:47, Juha Manninen:
[trim]

There are some cases already where you can use a semicolon or leave it out.

Not exactly, IMHO. The original point (AFAIK) was that semicolon is a separator. That is, it is to be used _between_ operators, not _inside_ of. And in accordance, originally pascal's "case" operator didn't feature the "else" part at all, so it was all clear and logical. You were always free to add as much semicolons as you wish, but _only_ where allowed by syntax - _between_ operators. Like:

begin
   DoThing1;
   DoThing2;;
   DoThing3;;;
   ;;;;;
end;

This would be perfectly valid even with 25 years' ago compilers. The last semicolon before "end" was never a requirement, because "end" is not an operator, so there is simply nothing to separate from. If you still put semicolon before the "end", it means you just add an implicite empty operator. You can do it just after "begin" if you like - it is harmless, though syntactically useless as well.
(And yes, I also have ; before "end" most of the time because of copy-pasting and typing reflex)

Nikolai

In our previous episode, Jonas Maebe said:

That it is binary, is. The point was more that it is a superset. A slightly lower level superset of the dialects supported more or less.

I don't know if a GCC frontend can directly parse headers in multiple languaes. It would mean multiple frontends in one binary and afaik the gcc frontends are separate binaries?

Marco van de Voort wrote

I don't know if a GCC frontend can directly parse headers in multiple languaes. It would mean multiple frontends in one binary and afaik the gcc frontends are separate binaries?

All the C frontends are in one binary. I was not talking about mixing C++ and Pascal in a single source file.

Jonas