> Florian Klaempfl <[EMAIL PROTECTED]> wrote:
> > >
> > > Is this correct so far?
>
> Ok. So, FPC will follow chrome/Delphi?
Afaik there is no need to. Chrome is as relevant as C++, since it is a
different language, and Delphi implements .NET stuff, and maybe provides a
backwards compat kludge f
Peter Vreman wrote:
The token-lookahead is a hack and will create more problems and
performance loss in a critical part of the compiler.
The restriction of type blocks only is not strange at all, Delphi allows
'class of' is also only in type blocks
Ok, I didn't know it would be a real ugly hac
Mattias Gaertner wrote:
On Mon, 07 Nov 2005 23:06:37 +0100
Florian Klaempfl <[EMAIL PROTECTED]> wrote:
Ok. So, FPC will follow chrome/Delphi?
I would do so, see my mail from the weekend :)
I see, but also I see all the other posts still discussing the syntax. I
wondered, if it was definitive
I use fpc 2.0.1 from svn & lazarus from svn on linux. After fpc revision 1659
and up I have this problem when I start lazarus with zeosdbo packages for
lazarus:
./startlazarus
Runtime error 210 at $08055B95
$08055B95
$0865E350 ZDBCDBLIB_init, line 737
of
/home/barkooo/freepascal/lazarus.
On Mon, 7 Nov 2005, Micha Nelissen wrote:
> On Mon, 07 Nov 2005 21:07:42 +0100
> Marc Weustink <[EMAIL PROTECTED]> wrote:
>
> > Params are passed to a procedure define like
> >
> >procedure MyProc(param, param, ..)
> >
> > Arrays are declared like
> >
> >A: array[0..9] of ...
> >
>
On Mon, 07 Nov 2005 23:06:37 +0100
Florian Klaempfl <[EMAIL PROTECTED]> wrote:
>[...]
> > Ok. So, FPC will follow chrome/Delphi?
>
> I would do so, see my mail from the weekend :)
I see, but also I see all the other posts still discussing the syntax. I
wondered, if it was definitive.
Mattias
_
On Mon, 07 Nov 2005 21:07:42 +0100
Marc Weustink <[EMAIL PROTECTED]> wrote:
> Params are passed to a procedure define like
>
>procedure MyProc(param, param, ..)
>
> Arrays are declared like
>
>A: array[0..9] of ...
>
> And generics they are soly defined by the fact that a type has
Mattias Gaertner wrote:
> On Mon, 07 Nov 2005 22:41:06 +0100
> Florian Klaempfl <[EMAIL PROTECTED]> wrote:
>
>
>>Mattias Gaertner wrote:
>>
>>>On Mon, 07 Nov 2005 19:29:51 +0100
>>>Bram Kuijvenhoven <[EMAIL PROTECTED]> wrote:
>>>
>>>
>>>
Micha Nelissen wrote:
>On Mon, 07 Nov 20
On Mon, 07 Nov 2005 22:41:06 +0100
Florian Klaempfl <[EMAIL PROTECTED]> wrote:
> Mattias Gaertner wrote:
> > On Mon, 07 Nov 2005 19:29:51 +0100
> > Bram Kuijvenhoven <[EMAIL PROTECTED]> wrote:
> >
> >
> >>Micha Nelissen wrote:
> >>
> >>>On Mon, 07 Nov 2005 14:45:19 +0100
> >>>Bram Kuijvenhoven <
Mattias Gaertner wrote:
> On Mon, 07 Nov 2005 19:29:51 +0100
> Bram Kuijvenhoven <[EMAIL PROTECTED]> wrote:
>
>
>>Micha Nelissen wrote:
>>
>>>On Mon, 07 Nov 2005 14:45:19 +0100
>>>Bram Kuijvenhoven <[EMAIL PROTECTED]> wrote:
>>>
Does <> for generics fit into Pascal? Well, we use [] for array
On Mon, 7 Nov 2005, Anton Tichawa wrote:
> Marc Weustink wrote:
>
> > Bram Kuijvenhoven wrote:
> >
> > > Micha Nelissen wrote:
> > >
> > > > Bram Kuijvenhoven wrote:
> > > >
> > > > > Florian Klaempfl wrote:
> > > > >
> > > > > > - we'll use a syntax as close as possible to Chrome, e.g.
> >
Marc Weustink wrote:
Bram Kuijvenhoven wrote:
Micha Nelissen wrote:
Bram Kuijvenhoven wrote:
Florian Klaempfl wrote:
- we'll use a syntax as close as possible to Chrome, e.g.
type
TList = class
...
end;
I greatly favor this syntaxis above the generic-modifier. It will
look a
Michael Van Canneyt wrote:
On Mon, 7 Nov 2005 [EMAIL PROTECTED] wrote:
Marco van de Voort wrote:
Interesting switch in FPC 2.1.1:
-Skload fpcylix unit
what is it for?
Afaik it implicitely USES the fpcylix unit that contains some identifiers
for Kylix compat that
Bram Kuijvenhoven wrote:
Micha Nelissen wrote:
Bram Kuijvenhoven wrote:
Florian Klaempfl wrote:
- we'll use a syntax as close as possible to Chrome, e.g.
type
TList = class
...
end;
I greatly favor this syntaxis above the generic-modifier. It will
look at a lot more familiar to
On Mon, 7 Nov 2005 [EMAIL PROTECTED] wrote:
> Marco van de Voort wrote:
>
> > > Interesting switch in FPC 2.1.1:
> > >
> > > -Skload fpcylix unit
> > >
> > > what is it for?
> > >
> > >
> >
> > Afaik it implicitely USES the fpcylix unit that contains some identifiers
> > for Kylix
On Mon, 07 Nov 2005 19:29:51 +0100
Bram Kuijvenhoven <[EMAIL PROTECTED]> wrote:
> Micha Nelissen wrote:
> > On Mon, 07 Nov 2005 14:45:19 +0100
> > Bram Kuijvenhoven <[EMAIL PROTECTED]> wrote:
> >>Does <> for generics fit into Pascal? Well, we use [] for array
> >indexing, and () for parameter pass
Micha Nelissen wrote:
On Mon, 07 Nov 2005 14:45:19 +0100
Bram Kuijvenhoven <[EMAIL PROTECTED]> wrote:
Does <> for generics fit into Pascal? Well, we use [] for array indexing, and () for
parameter passing to procedures/functions/methods. So why not use <> for passing parameters
to generic type
> Marco van de Voort wrote:
> >
> >Afaik it implicitely USES the fpcylix unit that contains some identifiers
> >for Kylix compat that we _really_ didn't want in the normal system/sysutils
> >unit.
> >
> Is FPC able to compile Kylix forms (*.xfm) now?
Forms are something of a higher level than FPC.
Marco van de Voort wrote:
Interesting switch in FPC 2.1.1:
-Skload fpcylix unit
what is it for?
Afaik it implicitely USES the fpcylix unit that contains some identifiers
for Kylix compat that we _really_ didn't want in the normal system/sysutils
unit.
On Mon, 07 Nov 2005 14:45:19 +0100
Bram Kuijvenhoven <[EMAIL PROTECTED]> wrote:
> Does <> for generics fit into Pascal? Well, we use [] for array indexing, and
> () for parameter passing to procedures/functions/methods. So why not use <>
> for passing parameters to generic types? And, similar to
Thomas Schatzl wrote:
From: Ales Katona <[EMAIL PROTECTED]>
What about simply disabling such -Ct compiler switch (with nice error
message) under Windows ? Or maybe it should "do nothing" under
Windows ?
I have no idea how -Ct works. It seems there are also report(by Pavel
to be more prec
> Micha Nelissen wrote:
> Consider for example the following: Is Java bad because it looks like C++?
No. But it inherits from C syntax in nearly all forms.
The test is consistency. Java is consistent if it follows C(++) syntax,
(the rest of the language is C(++) like), (free)pascal not,
> Or
Micha Nelissen wrote:
Bram Kuijvenhoven wrote:
Florian Klaempfl wrote:
- we'll use a syntax as close as possible to Chrome, e.g.
type
TList = class
...
end;
I greatly favor this syntaxis above the generic-modifier. It will look
at a lot more familiar to most programmers (due to e.g.
> Peter Vreman wrote:
> TStringMyObjectMap = TMap;
>
> etc.
>
> One more question: If I understand it correctly, the parser uses a
> recursive top-down recursive descent approach and not a bottom-up approach
> like the LALR parsers generated by the pyacc tool?
Correct. Pascal tools usually do.
Peter Vreman wrote:
The token-lookahead is a hack and will create more problems and
performance loss in a critical part of the compiler.
The restriction of type blocks only is not strange at all, Delphi allows
'class of' is also only in type blocks
Ok, I didn't know it would be a real ugly hac
From: Ales Katona <[EMAIL PROTECTED]>
What about simply disabling such -Ct compiler switch (with nice error
message) under Windows ? Or maybe it should "do nothing" under Windows ?
I have no idea how -Ct works. It seems there are also report(by Pavel to
be more precise) that -Ct causes proble
Bram Kuijvenhoven wrote:
Florian Klaempfl wrote:
- we'll use a syntax as close as possible to Chrome, e.g.
type
TList = class
...
end;
I greatly favor this syntaxis above the generic-modifier. It will look
at a lot more familiar to most programmers (due to e.g. C++ and Java),
"Mu
>> - instantiation will be only possible in declaration blocks, not in code
>> blocks:
>> possible:
>> var
>> mylist : TList;
>> const
>> mylist : TList = nil;
>> type
>> mylist = TList;
>> forbidden:
>> procedure p(mylist : TList);
>> begin
>> ...
>> mylist:=TList.create;
>> ...
>> end
Hi! I've been following the generic discussion with great interest. Here are
some of my thoughts.
Florian Klaempfl wrote:
- we'll use a syntax as close as possible to Chrome, e.g.
type
TList = class
...
end;
I greatly favor this syntaxis above the generic-modifier. It will look at a l
Tomas Hajny wrote:
> Marco van de Voort wrote:
>
>>>Interesting switch in FPC 2.1.1:
>>>
>>> -Skload fpcylix unit
>>>
>>>what is it for?
>>
>>Afaik it implicitely USES the fpcylix unit that contains some identifiers
>>for Kylix compat that we _really_ didn't want in the normal
>>system/
Marco van de Voort wrote:
>> Interesting switch in FPC 2.1.1:
>>
>>-Skload fpcylix unit
>>
>> what is it for?
>
> Afaik it implicitely USES the fpcylix unit that contains some identifiers
> for Kylix compat that we _really_ didn't want in the normal
> system/sysutils
> unit.
BTW, looki
[EMAIL PROTECTED] wrote:
Marco van de Voort wrote:
Interesting switch in FPC 2.1.1:
-Skload fpcylix unit
what is it for?
Afaik it implicitely USES the fpcylix unit that contains some identifiers
for Kylix compat that we _really_ didn't want in the normal
system/sysutils
unit
>>>Interesting switch in FPC 2.1.1:
>>>
>>> -Skload fpcylix unit
>>>
>>>what is it for?
>>Afaik it implicitely USES the fpcylix unit that contains some identifiers
>>for Kylix compat that we _really_ didn't want in the normal
>> system/sysutils
>>unit.
> where can i find it ?
~/fpc>>> fi
Marco van de Voort wrote:
Interesting switch in FPC 2.1.1:
-Skload fpcylix unit
what is it for?
Afaik it implicitely USES the fpcylix unit that contains some identifiers
for Kylix compat that we _really_ didn't want in the normal system/sysutils
unit.
> Interesting switch in FPC 2.1.1:
>
>-Skload fpcylix unit
>
> what is it for?
Afaik it implicitely USES the fpcylix unit that contains some identifiers
for Kylix compat that we _really_ didn't want in the normal system/sysutils
unit.
___
35 matches
Mail list logo
