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
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
http://lists.freepascal.org/mailman/listinfo/f
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
Maybe StringToPPChar should be fixed instead?
thanks,
dmitry
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
40 matches
Mail list logo
