Maybe StringToPPChar should be fixed instead?
thanks,
dmitry
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
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
On Fri, Jan 29, 2010 at 08:56, Thaddy tha...@thaddy.com 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
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
On Fri, Jan 29, 2010 at 08:09, Graeme Geldenhuys
graemeg.li...@gmail.com 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
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 10:22, Juha Manninen juha.manni...@phnet.fi 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
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,
On Fri, Jan 29, 2010 at 11:36, Juha Manninen juha.manni...@phnet.fi 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
On Fri, Jan 29, 2010 at 11:42, Michael Van Canneyt
mich...@freepascal.org 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
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.
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
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
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
Aleksa Todorovic wrote:
On Fri, Jan 29, 2010 at 11:42, Michael Van Canneyt
mich...@freepascal.org 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.
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
On Fri, Jan 29, 2010 at 12:11, Marc Weustink marc.weust...@cuperus.nl wrote:
Aleksa Todorovic wrote:
On Fri, Jan 29, 2010 at 11:42, Michael Van Canneyt
mich...@freepascal.org wrote:
It breaks the behavious of case:
case b of
1 : something;
2 : If a then
DoSomethingElse;
else
On Fri, Jan 29, 2010 at 2:08 PM, Marco van de Voort mar...@stack.nl 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,
Il 29/01/2010 08:25, Paul Ishenin ha scritto:
Together with Dmitry we found the solution. Patch is attached.
Thanks, applied in rev 14824
Giulio
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
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 translating e.g.
Aleksa Todorovic wrote:
On Fri, Jan 29, 2010 at 12:11, Marc Weustinkmarc.weust...@cuperus.nl wrote:
Aleksa Todorovic wrote:
On Fri, Jan 29, 2010 at 11:42, Michael Van Canneyt
mich...@freepascal.orgwrote:
It breaks the behavious of case:
case b of
1 : something;
2 : If a then
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
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
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, without
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
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
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
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 be
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.
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
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
On Fri, Jan 29, 2010 at 13:23, Marco van de Voort mar...@stack.nl 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
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
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
On Fri, Jan 29, 2010 at 16:22, Jonas Maebe jonas.ma...@elis.ugent.be 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
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 fact that
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 about
38 matches
Mail list logo
