On 29 Jan 2010, at 21:17, 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 abo
In our previous episode, Jonas Maebe said:
> > 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 fac
On Fri, Jan 29, 2010 at 16:22, Jonas Maebe wrote:
>
> On 29 Jan 2010, at 16:12, Aleksa Todorovic 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 n
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 pa
On 29 Jan 2010, at 16:12, Aleksa Todorovic 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 "manuall
On Fri, Jan 29, 2010 at 13:23, 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 "ma
On 29 Jan 2010, at 15:08, Marco van de Voort wrote:
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 precompile
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
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 h
On 29 Jan 2010, at 14:40, Juha Manninen wrote:
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.
I
In our previous episode, Juha Manninen said:
> > 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
> 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.
> Units compiled in different dialects can indeed b
On 29 Jan 2010, at 14:10, 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
On 1/29/2010 4:22 AM, 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 thing at all. You have redefined
the language is a subtle but significant way.
I fear if
> 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 a
Marc Weustink wrote:
>
> So this feature is inconsistent ?
+1
> 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, wit
Matt Emson wrote:
It is just a risk without real benefit attached to it, so I'm against.
+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 f
Matt Emson wrote:
Stefan Kisdaroczi wrote:
Am 29.01.2010 12:08, schrieb Marco van de Voort:
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
Aleksa Todorovic wrote:
On Fri, Jan 29, 2010 at 12:11, Marc Weustink wrote:
Aleksa Todorovic wrote:
On Fri, Jan 29, 2010 at 11:42, Michael Van Canneyt
wrote:
It breaks the behavious of case:
case b of
1 : something;
2 : If a then
DoSomethingElse;
else
DoElse
end;
As it is
In our previous episode, dmitry boyarintsev said:
> > possible syntax.
> >
> > It is just a risk without real benefit attached to it, so I'm against.
>
> +1
> why should pascal care about C legacy?
Depends. I do see a minor point for e.g. ++ and --, since I have been bitten
by that when translati
On Fri, Jan 29, 2010 at 2:08 PM, Marco van de Voort wrote:
> 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 agai
On Fri, Jan 29, 2010 at 12:11, Marc Weustink wrote:
> Aleksa Todorovic wrote:
>>
>> On Fri, Jan 29, 2010 at 11:42, Michael Van Canneyt
>> wrote:
>>>
>>> It breaks the behavious of case:
>>>
>>> case b of
>>> 1 : something;
>>> 2 : If a then
>>> DoSomethingElse;
>>> else
>>> DoElse
>>> e
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
DoThi
Aleksa Todorovic wrote:
On Fri, Jan 29, 2010 at 11:42, Michael Van Canneyt
wrote:
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
Stefan Kisdaroczi wrote:
Am 29.01.2010 12:08, schrieb Marco van de Voort:
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,
Am 29.01.2010 12:08, schrieb Marco van de Voort:
> 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
>
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 disambi
As well as both
if a then
DoSomething
else
DoOtherThing;
and
if a then
DoSomething;
else
DoOtherThing;
At least to me they are :-)
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.
On Fri, Jan 29, 2010 at 11:42, Michael Van Canneyt
wrote:
>
> 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 w
On Fri, Jan 29, 2010 at 11:36, 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.
___
On Fri, 29 Jan 2010, Juha Manninen wrote:
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,
> 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 M
On Fri, Jan 29, 2010 at 10:22, 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 :-)
Pete Cervasio wrote:
On Friday 29 January 2010 01:52:59 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?
On Fri, Jan 29, 2010 at 08:09, Graeme Geldenhuys
wrote:
>
> 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;
As we
>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
On Fri, Jan 29, 2010 at 08:56, Thaddy wrote:
> Aleksa Todorovic wrote:
>>
>> else is handled as part of "if b then" -> the closest preceeding if:
>
> This would break almost all my code.
Hm... it shouldn't. As far as I tested it, it correctly handles all
possible situations. If it doesn't take yo
On Friday 29 January 2010 01:52:59 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
Aleksa Todorovic wrote:
else is handled as part of "if b then" -> the closest preceeding if:
This would break almost all my code.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
> if x < 2 then
> if x > 0 then
> Writeln('x=1');
> else
> Writeln('x=0');
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'
Aleksa Todorovic wrote:
>> if a then
>>if b then
>> DoSomething;
>> else
>> DoOtherThing;
>>
>
> else is handled as part of "if b then" -> the closest preceeding if:
That is so confusing... if the major issue is that if you wanted to add
more lines before of after the else, then si
On Fri, Jan 29, 2010 at 00:00, Juha Manninen wrote:
>
> How does your patch handle this? :
>
> if a then
> if b then
> DoSomething;
> else
> DoOtherThing;
>
else is handled as part of "if b then" -> the closest preceeding if:
program test3;
var
x: Integer;
begin
x := 1;
if x
How does your patch handle this? :
if a then
if b then
DoSomething;
else
DoOtherThing;
Syntax error
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
> - 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 ch
On Tue, Jan 26, 2010 at 10:56, Juha Manninen wrote:
>
> 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.
I'm trying to solve that on
On Tue, Jan 26, 2010 at 07:42, 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
Marco van de Voort wrote:
In our previous episode, Aleksa Todorovic said:
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.
Agree fully, that'
On Tue, 2010-01-26 at 09:23 +0200, Graeme Geldenhuys wrote:
> 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 i
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,
- Gr
On Tue, Jan 26, 2010 at 11:27, Michael Schnell wrote:
> On 01/26/2010 07:51 AM, 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 c
On Tue, Jan 26, 2010 at 07:42, Graeme Geldenhuys
wrote:
> David W Noon wrote:
>
> 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
>
> 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 comma
On 01/26/2010 07:51 AM, 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
_
On 01/26/2010 07:51 AM, 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
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://
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
___
fpc-devel maillist - fpc-devel@lists.fr
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 irr
In our previous episode, Aleksa Todorovic said:
> >> 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.
> >
> > Agree fully, that's how W
On 2010-01-26 16:51, Graeme Geldenhuys wrote:
> David W Noon wrote:
>> >
>> > [snip]
>>> >> 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 fo
On Tue, Jan 26, 2010 at 10:11, Marco van de Voort wrote:
> In our previous episode, Mark Morgan Lloyd said:
>>
>> > 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
In our previous episode, Mark Morgan Lloyd said:
>
> > 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
> bu
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 synta
Thank you for your responses.
On Tue, Jan 26, 2010 at 08:23, Graeme Geldenhuys
wrote:
> 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.
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 co
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 modifyi
David W Noon wrote:
>
> [snip]
>> 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.
>
> A quick examination of Jensen & Wirth's original Pascal grammar will
> te
On Tue, 26 Jan 2010 01:08:45 +0100, Aleksa Todorovic wrote about
[fpc-devel] Semicolon before else:
[snip]
> 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
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 t
67 matches
Mail list logo
