Re: [fpc-devel] Templates / Generics; Vote
As far as voting goes, personally, I prefer something like this: GList = generic class(T) And, are we going to have non-class rotines, such as event declarations; i.e. TGenericCallback = generic function(AValue1: TGenericValue; AValue2: TGenericValue): Integer; TSomeGenericEvent = generic procedure(ASender: TObject; ACallBack: TGenericCallback) of object; ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics; Vote
Micha Nelissen wrote: Ok, to prove this, I've added some ugly examples posted on IRC in the wiki. Look at the bottom of generic keyword syntax examples. Anyone an idea ? :-) Ok I've posted under "Suggestion 2" a slightly modified syntax. Let me know what you think. Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics; Vote
> > > > Pro <> reason will probably be: "compatibility". > > Pro "generic" will probably be: more Pascal-alike/readability. > > > Delphi.Net2.0 is using <> > Chrome is using <> > C# is using <> > C/C++ is using <> > > Why should FPC use "generics" ??? Why not if it is better readable and in the parser? None of the template using code in these will port to FPC regardless. People that can't memorise this difference shouldn't be using generics at all :) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics; Vote
Micha Nelissen wrote: Come on, we're just discussing pros and cons, who knows what the final syntax will be? Ok, to prove this, I've added some ugly examples posted on IRC in the wiki. Look at the bottom of generic keyword syntax examples. Anyone an idea ? :-) Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics; Vote
On Wed, 09 Nov 2005 19:16:46 +0100 [EMAIL PROTECTED] wrote: > Delphi.Net2.0 is using <> Uncertain. > Chrome is using <> Not inventive enough to come up with something of their own and simply following .NET C# syntax. > C# is using <> Duh. It's a C derivative. > C/C++ is using <> Duh, they like short symbols. > Why should FPC use "generics" ??? Because we like it? > That b.s. will break the Delphi code base! Who the *hell* are you with that tone?! Come on, we're just discussing pros and cons, who knows what the final syntax will be? Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics; Vote
[EMAIL PROTECTED] wrote: Delphi.Net2.0 is using <> Chrome is using <> C# is using <> C/C++ is using <> Why should FPC use "generics" ??? Why should FPC be Pascal-ish? Is that your question? :-) mm ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics; Vote
[EMAIL PROTECTED] wrote: Delphi.Net2.0 is using <> Chrome is using <> C# is using <> C/C++ is using <> Why should FPC use "generics" ??? Because it is more readable. < is an operator and therefore should not be used as bracket in generic definition. That b.s. will break the Delphi code base! What is b.s.? If it means (somehow) syntax for generics, then this argument is easy to refute: 1. There is no native (i.e. win32) Delphi code base (yet) that uses generics, so that won't be broken. 2. Delphi.Net 2.0 code is not yet released and exact syntax is therefore subject to change, so it cannot be used as example. Vincent. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics; Vote
Micha Nelissen wrote: Mattias Gaertner wrote: Hi all, I want to push generics to the next level. For those not familar, there is already a wiki about this topic: http://www.freepascal.org/wiki/index.php/Generics I have tried to organize the "usage example" section a bit, I think most of the "(uncategorized)" items can be removed now (authors of respective pieces: please do clean up if possible, or reply here if it's really new/adds something). Also, for the sake of it, I added a Vote page: http://www.freepascal.org/wiki/index.php/Generics_Vote Pro <> reason will probably be: "compatibility". Pro "generic" will probably be: more Pascal-alike/readability. Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel Delphi.Net2.0 is using <> Chrome is using <> C# is using <> C/C++ is using <> Why should FPC use "generics" ??? That b.s. will break the Delphi code base! ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics; Vote
On Wed, 9 Nov 2005, Micha Nelissen wrote: Mattias Gaertner wrote: Hi all, I want to push generics to the next level. For those not familar, there is already a wiki about this topic: http://www.freepascal.org/wiki/index.php/Generics I have tried to organize the "usage example" section a bit, I think most of the "(uncategorized)" items can be removed now (authors of respective pieces: please do clean up if possible, or reply here if it's really new/adds something). Also, for the sake of it, I added a Vote page: http://www.freepascal.org/wiki/index.php/Generics_Vote Pro <> reason will probably be: "compatibility". Pro "generic" will probably be: more Pascal-alike/readability. I'd really like to vote, but refuse to log in. I've had to re-think of a username and password already way too much for this &@#§! wiki. So feel free to add my name under 'pro generic' if you want to count my vote ;-) Michael.___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics; Vote
Mattias Gaertner wrote: Hi all, I want to push generics to the next level. For those not familar, there is already a wiki about this topic: http://www.freepascal.org/wiki/index.php/Generics I have tried to organize the "usage example" section a bit, I think most of the "(uncategorized)" items can be removed now (authors of respective pieces: please do clean up if possible, or reply here if it's really new/adds something). Also, for the sake of it, I added a Vote page: http://www.freepascal.org/wiki/index.php/Generics_Vote Pro <> reason will probably be: "compatibility". Pro "generic" will probably be: more Pascal-alike/readability. Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Rw: [fpc-devel] Templates / Generics
On Tue, 8 Nov 2005 [EMAIL PROTECTED] wrote: > Michael Van Canneyt wrote: > >Then they have to publish their specs real soon now. And I mean > >not > >something in a blog, but more something like documentation. We > >can't wait > >another 5 years, until they finally make up their mind. > > > Generics are already standardized. > > >>>Which standard is that ? C++ ? C# ? VB ? > >>> > >>ECMA Standard 334 > > > >But this is a standard for C#, so totally useless for Pascal syntax-wise. > > > Why useless? You can do exactly the same in a Pascal-styled way. > We need just a minor part from the standard for the FPC compiler. You stated that we could know already what the delphi-syntax will be, if they add generics over two years. But we can't, since we don't know what 'pascal-styled' way they will choose. I would say that a pascal-way is adding the 'interface' keyword. Like in array's and such. This is already mentioned. The chances that Borland will choose another pascal-styled-syntax is huge. Besides of that, I don't find that delphi-incompatibility is a no-go-area. Especially if we (or they - the core team) are the first ones who implement this feature. And incompatibilities can be solved in Delphi mode. And in general: If we can do something better then Delphi, I choose for loosing the compatibility. Joost. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics
On Tue, 8 Nov 2005 [EMAIL PROTECTED] wrote: > Michael Van Canneyt wrote: > >Then they have to publish their specs real soon now. And I mean > >not > >something in a blog, but more something like documentation. We > >can't wait > >another 5 years, until they finally make up their mind. > > > Generics are already standardized. > > >>>Which standard is that ? C++ ? C# ? VB ? > >>> > >>ECMA Standard 334 > > > >But this is a standard for C#, so totally useless for Pascal syntax-wise. > > > Why useless? You can do exactly the same in a Pascal-styled way. > We need just a minor part from the standard for the FPC compiler. You stated that we could know already what the delphi-syntax will be, if they add generics over two years. But we can't, since we don't know what 'pascal-styled' way they will choose. I would say that a pascal-way is adding the 'interface' keyword. Like in array's and such. This is already mentioned. The chances that Borland will choose another pascal-styled-syntax is huge. Besides of that, I don't find that delphi-incompatibility is a no-go-area. Especially if we (or they - the core team) are the first ones who implement this feature. And incompatibilities can be solved in Delphi mode. And in general: If we can do something better then Delphi, I choose for loosing the compatibility. Joost. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics
> On Tue, 8 Nov 2005 [EMAIL PROTECTED] wrote: > > > > > Why should Borland reinvent the wheel? > > http://bdn.borland.com/article/0,1410,33383,00.html > > That they will not invent new functionality is clear. > But absolutely nothing is said about pascal _syntax_ for generics. > > How this is translated to the underlying CLI is something else, but > that need not concern us. > > No-one is questioning the possibilities of generics. Of the .NET generics for native use? Yes I am :_) I had a thread about this in borland.delphi.non-technical, and the base problem seems to be that generics can be only applied to a class using an interface. Of course in .NET nearly everything is an object. I haven't seen anything about native implementation yet. > We're questioning the syntax to be used. So I think even if some Delphi.NET2 syntax is revealed, we still can't do anything with it, till we know for sure if the native implementation is not some awful non-optimal kludge to allow .NET generics using code to compile on delphi/native. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics
[EMAIL PROTECTED] wrote: You stated that we could know already what the delphi-syntax will be, if they add generics over two years. But we can't, since we don't know what 'pascal-styled' way they will choose. I would say that a pascal-way is adding the 'interface' keyword. Like in array's and such. This is already mentioned. The chances that Borland will choose another pascal-styled-syntax is huge. Besides of that, I don't find that delphi-incompatibility is a no-go-area. Especially if we (or they - the core team) are the first ones who implement this feature. And incompatibilities can be solved in Delphi mode. And in general: If we can do something better then Delphi, I choose for loosing the compatibility. Joost. You have my absolutly insignificant voice on that one. I fully agree. Ales ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics
On Tue, 8 Nov 2005 [EMAIL PROTECTED] wrote: > Michael Van Canneyt wrote: > >Then they have to publish their specs real soon now. And I mean > >not > >something in a blog, but more something like documentation. We > >can't wait > >another 5 years, until they finally make up their mind. > > > Generics are already standardized. > > >>>Which standard is that ? C++ ? C# ? VB ? > >>> > >>ECMA Standard 334 > > > >But this is a standard for C#, so totally useless for Pascal syntax-wise. > > > Why useless? You can do exactly the same in a Pascal-styled way. > We need just a minor part from the standard for the FPC compiler. You stated that we could know already what the delphi-syntax will be, if they add generics over two years. But we can't, since we don't know what 'pascal-styled' way they will choose. I would say that a pascal-way is adding the 'interface' keyword. Like in array's and such. This is already mentioned. The chances that Borland will choose another pascal-styled-syntax is huge. Besides of that, I don't find that delphi-incompatibility is a no-go-area. Especially if we (or they - the core team) are the first ones who implement this feature. And incompatibilities can be solved in Delphi mode. And in general: If we can do something better then Delphi, I choose for loosing the compatibility. Joost. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics
On Tue, 8 Nov 2005 [EMAIL PROTECTED] wrote: > Mattias Gaertner wrote: > > > Why do you think, that Borland will use ECMA Standard 334 for C# for the > > Delphi generics? > > Is there any official page, document, statement? > > > > > > > Why should Borland reinvent the wheel? > http://bdn.borland.com/article/0,1410,33383,00.html That they will not invent new functionality is clear. But absolutely nothing is said about pascal _syntax_ for generics. How this is translated to the underlying CLI is something else, but that need not concern us. No-one is questioning the possibilities of generics. We're questioning the syntax to be used. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics
Mattias Gaertner wrote: Why do you think, that Borland will use ECMA Standard 334 for C# for the Delphi generics? Is there any official page, document, statement? Why should Borland reinvent the wheel? http://bdn.borland.com/article/0,1410,33383,00.html ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics
On Tue, 08 Nov 2005 21:06:10 +0100 [EMAIL PROTECTED] wrote: >[...] > >>ECMA Standard 334 > > > >But this is a standard for C#, so totally useless for Pascal syntax-wise. > > > Why useless? You can do exactly the same in a Pascal-styled way. > We need just a minor part from the standard for the FPC compiler. Why do you think, that Borland will use ECMA Standard 334 for C# for the Delphi generics? Is there any official page, document, statement? Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics
Michael Van Canneyt wrote: On Tue, 8 Nov 2005 [EMAIL PROTECTED] wrote: Michael Van Canneyt wrote: On Tue, 8 Nov 2005 [EMAIL PROTECTED] wrote: Vincent Snijders wrote: LOL. Then they have to publish their specs real soon now. And I mean not something in a blog, but more something like documentation. We can't wait another 5 years, until they finally make up their mind. Generics are already standardized. Which standard is that ? C++ ? C# ? VB ? ECMA Standard 334 But this is a standard for C#, so totally useless for Pascal syntax-wise. Why useless? You can do exactly the same in a Pascal-styled way. We need just a minor part from the standard for the FPC compiler. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics
On Tue, 8 Nov 2005 [EMAIL PROTECTED] wrote: > Michael Van Canneyt wrote: > > > On Tue, 8 Nov 2005 [EMAIL PROTECTED] wrote: > > > > > > > > > Vincent Snijders wrote: > > > > > > > > > > > > > LOL. > > > > > > > > Then they have to publish their specs real soon now. And I mean > > > > not > > > > something in a blog, but more something like documentation. We > > > > can't wait > > > > another 5 years, until they finally make up their mind. > > > > > > > > > > > > > > > Generics are already standardized. > > > > > > > > > > Which standard is that ? C++ ? C# ? VB ? > > > > > ECMA Standard 334 But this is a standard for C#, so totally useless for Pascal syntax-wise. Have you seen the VB syntax on the website you recommend ? It may be 'only' VB, but it's at least a more clear syntax than the C#/C++ one. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics
[EMAIL PROTECTED] wrote: Michael Van Canneyt wrote: On Tue, 8 Nov 2005 [EMAIL PROTECTED] wrote: Vincent Snijders wrote: LOL. Then they have to publish their specs real soon now. And I mean not something in a blog, but more something like documentation. We can't wait another 5 years, until they finally make up their mind. Generics are already standardized. Which standard is that ? C++ ? C# ? VB ? ECMA Standard 334 According to Borland, the Win32 Gernerics syntax will be a subset of the .Net sytanx. And do they have .Net generics in Delphi ? In Delphi 2007. Delphi.Net Generics syntax is defined by the .Net syntax. And I was thinking there is no .Net syntax, since .Net is available for a wide range of languages with different syntaxes. Or maybe I don't know the meaning of the word syntax. Vincent. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics
Michael Van Canneyt wrote: On Tue, 8 Nov 2005 [EMAIL PROTECTED] wrote: Vincent Snijders wrote: LOL. Then they have to publish their specs real soon now. And I mean not something in a blog, but more something like documentation. We can't wait another 5 years, until they finally make up their mind. Generics are already standardized. Which standard is that ? C++ ? C# ? VB ? ECMA Standard 334 According to Borland, the Win32 Gernerics syntax will be a subset of the .Net sytanx. And do they have .Net generics in Delphi ? In Delphi 2007. Delphi.Net Generics syntax is defined by the .Net syntax. If they don't, the syntax is still open. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics
On Tue, 8 Nov 2005 [EMAIL PROTECTED] wrote: > Vincent Snijders wrote: > > > LOL. > > > > Then they have to publish their specs real soon now. And I mean not > > something in a blog, but more something like documentation. We can't wait > > another 5 years, until they finally make up their mind. > > > Generics are already standardized. Which standard is that ? C++ ? C# ? VB ? > According to Borland, the Win32 Gernerics > syntax will be a subset of the .Net sytanx. And do they have .Net generics in Delphi ? If they don't, the syntax is still open. Michel. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics
Vincent Snijders wrote: LOL. Then they have to publish their specs real soon now. And I mean not something in a blog, but more something like documentation. We can't wait another 5 years, until they finally make up their mind. Generics are already standardized. According to Borland, the Win32 Gernerics syntax will be a subset of the .Net sytanx. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics
[EMAIL PROTECTED] wrote: Marco van de Voort wrote: Delphi incompatibility is a NoGo for FPC. LOL. Then they have to publish their specs real soon now. And I mean not something in a blog, but more something like documentation. We can't wait another 5 years, until they finally make up their mind. Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics
Marco van de Voort wrote: 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 for win32 at best. For us, native is the core platform, and how they twist themselves to achieve compat between .NET and win32 (and how much .NET syntax they borrow) is not our problem. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel Delphi incompatibility is a NoGo for FPC. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics
Hi, Am Freitag, den 04.11.2005, 19:33 +0100 schrieb Peter Vreman: > At 18:17 4-11-2005, you wrote: > >This is evaluated by the pre-compiler run during compile time. > > > >When you use the template with e.g. > >var > >bl: List; > > > >then procedure show(s:string) is taken. > > > > But what if the bl: List is called from an other unit? The > Show(string) is then not visible anymore? Put the Show(string) into the ppu too, with a mangled name, and save any calls of Show within the generic type implementation to the ppu, writing the mangled name. Excuse the stupid made-up example below, but I can't think of anything that really _needs_ global functions right now, so I cheated by using class functions and a global catch-all variable to require a global translation function: unit ubaz; interface type TCache = generic(T: TObject) class(TObject) published class procedure Put(Name: string; Instance: T); class function Get(Name: string): T; end; implementation var gCachedObjects: array of TObject; gCachedNames: array of string; function FooToBar(Name: string; Instance: TObject): string; begin Result := T.ClassName + '_' + Name; end; class procedure TCache.Put(Name: string; Instance: T); begin SetLength(gCachedObjects, Length(gCachedObjects) + 1); SetLength(gCachedNames, Length(gCachedNames) + 1); gCachedObjects[High(gCachedObjects)] := Instance; gCachedNames[High(gCachedNames)] := FooToBar(Name, Instance); end; class function TCache.Get(Name: string): T; var i: Integer; begin Result := nil; for i := 0 to High(gCachedNames) do begin if gCachedNames[i] = Name then begin if gCachedObjects[i] is T then begin Result := gCachedObjects[i]; end; Break; end; end; end; end. the generated ppu should have $Private$FooToBar$string$TObject: function ($2843423) and the generic parts: gCachedNames[High(gCachedNames)] := uBaz.$Private$FooToBar(Name, Instance); Or did I miss something important ? (apart from the act of auto-publishing of the function although it is not in the interface section being a bit evil) cheers, Danny [...] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics
> Marco van de Voort wrote: > > I know Chrome is .NET oriented Delphians pet peeve, but compability wise it > > is irrelevant. It is only interesting for Delphians that really leave > > delphi(.net) behind, but then C# is a choice as well. > > So what you're saying is Chrome is only used by people who hate Borland > and hate Microsoft but still want .NET (for it's GC and library, I > assume) ? :-) Roughly. I'd say - they don't want C# because they are scared of C syntax. - they don't like Delphi.NET because it is less Delphi.NET due to its win32 compat. Afaik a very small group. Everybody seems to experiment with chrome, but I hear only few people that actually use it. (and that means that uptake is really low, since even Delphi.NET is that popular, a lot of .NETties directly move to MS VS tools) > Is Chrome not language (backward) compatible to Delphi.NET ? (I don't > know Chrome that well.) Afaik, no. Chrome is not frpm Borland. > I mean, if so, then people cannot migrate from > Delphi.NET to Chrome ... so I wonder how many people are using it then ? I know none that use it for production use. All people that use Delphi.NET seem to play with it, but I can't remember definite crossovers. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics
Marco van de Voort wrote: I know Chrome is .NET oriented Delphians pet peeve, but compability wise it is irrelevant. It is only interesting for Delphians that really leave delphi(.net) behind, but then C# is a choice as well. So what you're saying is Chrome is only used by people who hate Borland and hate Microsoft but still want .NET (for it's GC and library, I assume) ? :-) Is Chrome not language (backward) compatible to Delphi.NET ? (I don't know Chrome that well.) I mean, if so, then people cannot migrate from Delphi.NET to Chrome ... so I wonder how many people are using it then ? Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics
> On Tue, 8 Nov 2005, Marco van de Voort wrote: > > Later on, the -MDelphi switch can be used to implement > delphi-compatible parsing. If they do it differently > from chrome, then we'll implement -MChrome... I don't see any relation between FPC and Chrome. Non trivial Chrome code won't ever run under FPC and vice versa. (at the very least string indexing is 0 based under Chrome, but IIRC constructor and destructor behaviour also) I know Chrome is .NET oriented Delphians pet peeve, but compability wise it is irrelevant. It is only interesting for Delphians that really leave delphi(.net) behind, but then C# is a choice as well. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics
On Tue, 8 Nov 2005, Marco van de Voort wrote: 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 for win32 at best. For us, native is the core platform, and how they twist themselves to achieve compat between .NET and win32 (and how much .NET syntax they borrow) is not our problem. Exactly. That is why I prefer a more 'object pascal' syntax, and not this preprocessor-like stuff. Later on, the -MDelphi switch can be used to implement delphi-compatible parsing. If they do it differently from chrome, then we'll implement -MChrome... Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics
> 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 for win32 at best. For us, native is the core platform, and how they twist themselves to achieve compat between .NET and win32 (and how much .NET syntax they borrow) is not our problem. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics
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 hack. And you are right about the 'class of'. It is in fact very similar, as we can extend the conventions regarding naming as follows: type TMyObject = class ... end; TMyObjectClass = class of TMyObject; TMyObjectList = TList; TMyObjectSet = TSet; 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? Bram ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics
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 didn't know there was already decided on the syntaxis. So that's why I wrote about it in my mail. And from there the discussion started again (I think). So I will stop discussing it and wait for the first generic-capable compiler version :) (it is definitely true that the syntax isn't the hardest part of the implementation!) Bram ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics
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 ... > > > > And generics they are soly defined by the fact that a type has <> in it. > > Well generics *are* a kind of "parameterised" type. When you choose types > for the parameters, then the type is fully defined, just like the result of > a not-with-outside-interacting procedure would be when it's parameters are > filled in. When you view it this way, Bram has a point. > > I am still a proponent of a keyword btw, which I've documented at wiki: > > http://www.freepascal.org/wiki/index.php/Generics#Terms > > (just scroll a little upwards). This is because it generalizes better to > function generics, I think that in "Max(Foo: Type): T" the > last T feels "out-of-scope", while it doesn't when you have the generic > keyword because you're defining a "function generic(T) ..." > > Of course, these are all minor details compared to actual implementation. I second this proposal. But I _don't_ think that this is a minor detail. One of the nice things about (Object) Pascal is the readability. The <> does away with that. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics
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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics
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 <> in it. Well generics *are* a kind of "parameterised" type. When you choose types for the parameters, then the type is fully defined, just like the result of a not-with-outside-interacting procedure would be when it's parameters are filled in. When you view it this way, Bram has a point. I am still a proponent of a keyword btw, which I've documented at wiki: http://www.freepascal.org/wiki/index.php/Generics#Terms (just scroll a little upwards). This is because it generalizes better to function generics, I think that in "Max(Foo: Type): T" the last T feels "out-of-scope", while it doesn't when you have the generic keyword because you're defining a "function generic(T) ..." Of course, these are all minor details compared to actual implementation. Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics
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 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 the case of function calls and array indexing, these <> could follow >the type identifier directly. > >You got a point here, but the "where T is Foo" stuff is crap then, >>> >>>don't >>you agree? >>> >TGType = class(...) ... end; > >is better then, when compared to your parameter example. I indeed don't like the "where T is foo" of Chrome :) So you are totally right, TGType is a lot better and a lot more consistent (with e.g. function parameter syntaxis). >>> >>> >>>Let's sum up the different points for the syntax so far: >>> >>>- <> will probably be used by Delphi >>>- <> bites the < operator >> >>No, as I said, we should allow template instantiation only in type blocks. > > > type > TMyType = boolean(ab); > > :) Well, that's no problem either, the compiler knows that the < for parameter instantiation can only follow types being templates/generics :) Parsing is usually type driven in fpc. > > > >>>- <> makes the parser more difficult and slow >> >>See above. >> >> >>>- <> makes pascal more ambigious >> >>See above. >> >> >>>- alternatives: modifiers or not yet used brackets like (! !) or (# #) >> >>Ugly :) > > > Sure. But some people like emoticons. !) > > > > >>>It seems to me, it's a question of: Follow Delphi generics or not. >>>And we don't know, where Delphi will go. They will not have generics in >>>the next one and a half year and as always: They will do a few things >>>completely different than expected. >>>If we follow, then we will do, as Florian et al said. >>>If not, then the <> is not the best solution. >>> >>>Is this correct so far? > > > Ok. So, FPC will follow chrome/Delphi? I would do so, see my mail from the weekend :) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics
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 <[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 the case of function calls and array indexing, these <> could follow > >>>the type identifier directly. > >>> > >>>You got a point here, but the "where T is Foo" stuff is crap then, > >don't >>you agree? > >>> > >>>TGType = class(...) ... end; > >>> > >>>is better then, when compared to your parameter example. > >> > >>I indeed don't like the "where T is foo" of Chrome :) So you are totally > >>right, TGType is a lot better and a lot more consistent > >>(with e.g. function parameter syntaxis). > > > > > > Let's sum up the different points for the syntax so far: > > > > - <> will probably be used by Delphi > > - <> bites the < operator > > No, as I said, we should allow template instantiation only in type blocks. type TMyType = boolean(ab); :) > > - <> makes the parser more difficult and slow > > See above. > > > - <> makes pascal more ambigious > > See above. > > > - alternatives: modifiers or not yet used brackets like (! !) or (# #) > > Ugly :) Sure. But some people like emoticons. !) > > It seems to me, it's a question of: Follow Delphi generics or not. > > And we don't know, where Delphi will go. They will not have generics in > > the next one and a half year and as always: They will do a few things > > completely different than expected. > > If we follow, then we will do, as Florian et al said. > > If not, then the <> is not the best solution. > > > > Is this correct so far? Ok. So, FPC will follow chrome/Delphi? Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics
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 >>> >>>indexing, and () for parameter passing to procedures/functions/methods. >>>So why not use <> for passing parameters to generic types? And, similar >>>to the case of function calls and array indexing, these <> could follow >>>the type identifier directly. >>> >>>You got a point here, but the "where T is Foo" stuff is crap then, don't >>>you agree? >>> >>>TGType = class(...) ... end; >>> >>>is better then, when compared to your parameter example. >> >>I indeed don't like the "where T is foo" of Chrome :) So you are totally >>right, TGType is a lot better and a lot more consistent >>(with e.g. function parameter syntaxis). > > > Let's sum up the different points for the syntax so far: > > - <> will probably be used by Delphi > - <> bites the < operator No, as I said, we should allow template instantiation only in type blocks. > - <> makes the parser more difficult and slow See above. > - <> makes pascal more ambigious See above. > - alternatives: modifiers or not yet used brackets like (! !) or (# #) Ugly :) > > It seems to me, it's a question of: Follow Delphi generics or not. > And we don't know, where Delphi will go. They will not have generics in the > next one and a half year and as always: They will do a few things completely > different than expected. > If we follow, then we will do, as Florian et al said. > If not, then the <> is not the best solution. > > Is this correct so far? > > > Mattias > > ___ > fpc-devel maillist - fpc-devel@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-devel > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics
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. > > > > > > 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), > > > > > > > > > > > > > > > > "Must look familiar" programmers should be fired. > > > > > > > > > > > > Of course, the implementation of generics in Pascal should not depend > > > solely on how it is implemented in other languages. I should in the > > > first place fit into Pascal. > > > > > > Since it is already decided that it would be <> I didn't mix into the > > discussion anymore. However, I'll make a comment on this. > > > > > 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 the case of function > > > calls and array indexing, these <> could follow the type identifier > > > directly. > > > > > > 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 <> in > > it. > > > > That is imo inconsequent. > > > > Marc > > > I aggree. Why not use new keywords 'template', 'generic', like the current > 'array' or record'? That would make the code more readable, and remove > ambiguity problems. It won't cost much, compared to the total size of a > template. > > It's also more pascal-like, as opposed to C, where e. g. a pointer is denoted > with '*' and, at the same time, identifies an array etc. > > (sorry if this is out of time or had already been discussed - I just entered > this thread here). Personally, I also think that a keyword is in order, just as for 'Operator'. 'Generic' is the obvious choice. Something like TMyGenericClass = Generic Class (Ancestor,TemplateName) end; etc. the (,,,) syntax is used for interfaces as well, so that isn't too horrible. I think < > is an ugly C++ hack, and I would very much regret seeing the beautyful Object Pascal language butchered by such things. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics
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 at a lot more familiar to most programmers (due to e.g. C++ and Java), "Must look familiar" programmers should be fired. Of course, the implementation of generics in Pascal should not depend solely on how it is implemented in other languages. I should in the first place fit into Pascal. Since it is already decided that it would be <> I didn't mix into the discussion anymore. However, I'll make a comment on this. 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 the case of function calls and array indexing, these <> could follow the type identifier directly. 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 <> in it. That is imo inconsequent. Marc I aggree. Why not use new keywords 'template', 'generic', like the current 'array' or record'? That would make the code more readable, and remove ambiguity problems. It won't cost much, compared to the total size of a template. It's also more pascal-like, as opposed to C, where e. g. a pointer is denoted with '*' and, at the same time, identifies an array etc. (sorry if this is out of time or had already been discussed - I just entered this thread here). Anton ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics
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 most programmers (due to e.g. C++ and Java), "Must look familiar" programmers should be fired. Of course, the implementation of generics in Pascal should not depend solely on how it is implemented in other languages. I should in the first place fit into Pascal. Since it is already decided that it would be <> I didn't mix into the discussion anymore. However, I'll make a comment on this. 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 the case of function calls and array indexing, these <> could follow the type identifier directly. 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 <> in it. That is imo inconsequent. Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics
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 passing to procedures/functions/methods. > >So why not use <> for passing parameters to generic types? And, similar > >to the case of function calls and array indexing, these <> could follow > >the type identifier directly. > > > > You got a point here, but the "where T is Foo" stuff is crap then, don't > > you agree? > > > > TGType = class(...) ... end; > > > > is better then, when compared to your parameter example. > > I indeed don't like the "where T is foo" of Chrome :) So you are totally > right, TGType is a lot better and a lot more consistent > (with e.g. function parameter syntaxis). Let's sum up the different points for the syntax so far: - <> will probably be used by Delphi - <> bites the < operator - <> makes the parser more difficult and slow - <> makes pascal more ambigious - alternatives: modifiers or not yet used brackets like (! !) or (# #) It seems to me, it's a question of: Follow Delphi generics or not. And we don't know, where Delphi will go. They will not have generics in the next one and a half year and as always: They will do a few things completely different than expected. If we follow, then we will do, as Florian et al said. If not, then the <> is not the best solution. Is this correct so far? Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics
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 types? And, similar to the case of function calls and array indexing, these <> could follow the type identifier directly. You got a point here, but the "where T is Foo" stuff is crap then, don't you agree? TGType = class(...) ... end; is better then, when compared to your parameter example. I indeed don't like the "where T is foo" of Chrome :) So you are totally right, TGType is a lot better and a lot more consistent (with e.g. function parameter syntaxis). Bram ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics
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 the case of function > calls and array indexing, these <> could follow the type identifier directly. You got a point here, but the "where T is Foo" stuff is crap then, don't you agree? TGType = class(...) ... end; is better then, when compared to your parameter example. Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics
> 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 is PHP bad because is looks like C++?
Most scripting languages are basically historical amalgam of syntaxes, which
is also why they are not very suitable to write very large programs.
FPC is a general purpose language, which should be suitable to write large
programs. This requires some orthogonality of syntax, to make the errorrate
(due to syntax) as low as possible.
> I think it is even advantageous for programmers these languages have a
> similar syntaxis.
>
> Just as + means addition in most programming languages, <> is used for
> generics as far as I know in most languages supporting generics.
The problem is that all langs you list are C derivates. At least on the
syntax level (e.g. {} for blocks, semicolon as statement terminator etc)
> I think if other considerations tie, we should therefore choose for <> as
> well. I think this will at least add to popularity and also reduce RSI ;)
I won't speak out in favour or against <> here. I did this several times in
syntax discussions with Peter (and Florian/Jonas/Daniel too) before, and he
was always right.
One simply can't say do "this" up front, but really has to look into (or
know) the insides of the language to be able to predict if a change could be
ambiguous, and avoid loosing consistency of the language.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics
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. C++ and Java), "Must look familiar" programmers should be fired. Of course, the implementation of generics in Pascal should not depend solely on how it is implemented in other languages. I should in the first place fit into Pascal. 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 the case of function calls and array indexing, these <> could follow the type identifier directly. The only objection might be the ambiguity with the < operator. From that perspective, a solution like generic(T) might seem nice. But a solution for that was already proposed: only allow the use of <> in declaration blocks, not in code. Also, I wouldn't particularly consider genericness a modifier (but like parameters). Of course it is hard to discuss about matters of taste. Perhaps a poll might help us out here. Anyway, I think that seeking some syntactical familiarity (when other considerations more or less tie) isn't neccesarily bad. Consider for example the following: Is Java bad because it looks like C++? Or is PHP bad because is looks like C++? I think it is even advantageous for programmers these languages have a similar syntaxis. Just as + means addition in most programming languages, <> is used for generics as far as I know in most languages supporting generics. I think if other considerations tie, we should therefore choose for <> as well. I think this will at least add to popularity and also reduce RSI ;) Regards, Bram ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics
> 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. (and I heard GCC4 C++ is also RD) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics
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 hack. And you are right about the 'class of'. It is in fact very similar, as we can extend the conventions regarding naming as follows: type TMyObject = class ... end; TMyObjectClass = class of TMyObject; TMyObjectList = TList; TMyObjectSet = TSet; 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? Bram ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics
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), "Must look familiar" programmers should be fired. is more compact Pascal is about *readability* ! and moreover likely to be compatible with other implementations (Chrome, rumors about Delphi 11). Leave the rumors to rest. And who uses Chrome anyway ? :-P Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics
>> - 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; > > This seems like a smart and sufficient solution to avoid the problem of > parsing < tokens in code blocks. > > On the other hand, programmers will like it (a lot) more if they don't > need to separately define a type for every generic instantiation. Is the > token-lookahead approach proposed elsewhere in this thread not a > sufficient solution? If it is not very easy, or if we are quite unsure > about this for now, perhaps we can postpone the implementation of > in-code(block) generic instantiation to a later time and first implement > generics as above. 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics
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 lot more familiar to most programmers (due to e.g. C++ and Java), is more compact and moreover likely to be compatible with other implementations (Chrome, rumors about Delphi 11). I assume this also means that the generic type identifier has to be included in the method implementation, e.g. TList.Add(AValue: T); begin ... end; This would also allow overloading of generics, i.e. having (generic) classes with different numbers of type parameters, but the same name. E.g. having both a TList and a TList. (though a declaration like TList = TList could easily solve this in this case) How will we deal with restrictions on the type of a generic parameter? Chrome does this with for example Dictionary = public class where Key is IComparable, Key has constructor, Value is Component; And will it be possible to have type dependent specializations? E.g. TList.Add(AValue: T); ... TList.Add(AValue: T); ... This can allow for efficient implementations for certain specific types while using the same name. Though it more or less violates the write-once advantage of generics, efficiency and type name uniformity is still available I think. - 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; This seems like a smart and sufficient solution to avoid the problem of parsing < tokens in code blocks. On the other hand, programmers will like it (a lot) more if they don't need to separately define a type for every generic instantiation. Is the token-lookahead approach proposed elsewhere in this thread not a sufficient solution? If it is not very easy, or if we are quite unsure about this for now, perhaps we can postpone the implementation of in-code(block) generic instantiation to a later time and first implement generics as above. Maybe we need an exception to this when supporting sub routine templates: procedure p(mylist : TList); begin ... end; but this doesn't lead to an ambigious syntax. Because you can easily decide that a T following a < in the code is a generic parameter? (I assume you also allow TList.Create in the code block ... above?) - instantiation steps which require code generation are done after main program compilation based on information saved in the unit files, this has some advantages: - several equal instantiations require only one specialisation So TList and TList share the same code if nothing particular of the types TSomeNiceObject and TSomeOtherNiceObject is used in the generic? That is indeed quite important I think. Container classes often do not assume anything about the class they store, and otherwise we would get a lot of duplicate code in the resulting executables (for all different classes, which in fact all are 4 (or 8) byte pointers). - it's possible to setup an symbol environment as it has been used in the template definition, so the cyclic unit use problem is void it requires though that a lot symbols of the implementation part of a unit must be written to the unit file if the unit contains a template definition Will a generic implementation have access to procedures visible at the location where the generic is instantiated? It might seem at first to be a useful restriction to disallow this, because otherwise a TList in unit1 could need another specialisation than TList in unit2. But on the other hand, we might just want to allow it! Example: In the (imaginary) unit containers there might be a TSortedList class, which uses the < operator on T. In yourunit you define a type TYourType and an operator < operating on TYourType. If you now want use TSortedList in yourunit, it will need to pick up the operator defined in yourunit, which is not visible in the unit containers. Similar questions might arise with respect to code for Hashing a specific type for e.g. THashMap. Possible solutions appearing in my mind are that (1) a user has to write a function Hash(O: TYourType):integer; for every TYourType, or (2) adding Hash to TObject (like in Java) or to some class of interface (e.g. IHashable), where we need to be able to impose certain conditions on the generic parameters's types as in Chrome (see above). Note: Java has the Comparable interface and does not allow overloading of operators like < iirc (but C++ does of course). Regards, Bram ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics
What is Chrome? Some examples of Generics:
http://www.remobjects.com/articles/?id={A1D08EE3-0D9E-4828-AFB3-B2C1E772186E}
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics
dannym wrote: > hmm.. a parameter declaration of a function declaration is not a > declaration block ? I've always thought of them like local variables, > just happening to be pre-filled.. procedure p(a : array[0..10] of longint); isn't possible either. > > and, will TList and mylist be compatible types ? > > >>Maybe we need an exception to this when supporting sub routine templates: >>procedure p(mylist : TList); >>begin >>... >>end; >>but this doesn't lead to an ambigious syntax. >> >>- instantiation steps which require code generation are done after main >>program compilation based on information saved in the unit files, this >>has some advantages: > > > you mean to save the parse tree of the generic (both the interface and > the implementation section) to the ppu ? Inlining does this already, the infrastructure is in place. > I've been thinking about using > a extra file in order not to taint the ppu but if it is possible to use > the ppu itself for that, i'm all for it :) > > >>- several equal instantiations require only one specialisation > > > >>- it's possible to setup an symbol environment as it has been used in >>the template definition, so the cyclic unit use problem is void it >>requires though that a lot symbols of the implementation part of a unit >>must be written to the unit file if the unit contains a template definition > > > note that line number information for nice error messages need to be > retained along with the parse tree of the generic (so that when another > unit uses a generic unit but specializes it to something stupid, > programmer gets a nice location of error rather than "guess where it > was" :)). > Maybe it already is done, though :) > > Note that for the error message, you'll need _two_ locations: one of the > generic type implementation where the actual error manifested and one > for the location of the specialization of the generic, to know what has > been used as the type parameter. > > On second though, _maybe_ just one location (the first) and the names of > the types used for the type parameters suffice. For Inlining this works too. > > >>This approach will require some compiler clean ups but that isn't that >>bad ;) >> >>Any comments :)? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics
Hi, Am Freitag, den 04.11.2005, 20:28 +0100 schrieb Florian Klaempfl: > I read the disussion above and I'll post my thoughts so far below: > > - we'll use a syntax as close as possible to Chrome, e.g. > type > TList = class > ... > end; > > - 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; hmm.. a parameter declaration of a function declaration is not a declaration block ? I've always thought of them like local variables, just happening to be pre-filled.. and, will TList and mylist be compatible types ? > Maybe we need an exception to this when supporting sub routine templates: > procedure p(mylist : TList); > begin > ... > end; > but this doesn't lead to an ambigious syntax. > > - instantiation steps which require code generation are done after main > program compilation based on information saved in the unit files, this > has some advantages: you mean to save the parse tree of the generic (both the interface and the implementation section) to the ppu ? I've been thinking about using a extra file in order not to taint the ppu but if it is possible to use the ppu itself for that, i'm all for it :) > - several equal instantiations require only one specialisation > - it's possible to setup an symbol environment as it has been used in > the template definition, so the cyclic unit use problem is void it > requires though that a lot symbols of the implementation part of a unit > must be written to the unit file if the unit contains a template definition note that line number information for nice error messages need to be retained along with the parse tree of the generic (so that when another unit uses a generic unit but specializes it to something stupid, programmer gets a nice location of error rather than "guess where it was" :)). Maybe it already is done, though :) Note that for the error message, you'll need _two_ locations: one of the generic type implementation where the actual error manifested and one for the location of the specialization of the generic, to know what has been used as the type parameter. On second though, _maybe_ just one location (the first) and the names of the types used for the type parameters suffice. > > This approach will require some compiler clean ups but that isn't that > bad ;) > > Any comments :)? cheers, Danny ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics
On Fri, 04 Nov 2005 20:28:15 +0100 Florian Klaempfl <[EMAIL PROTECTED]> wrote: > - instantiation steps which require code generation are done after main > program compilation based on information saved in the unit files, this > has some advantages: If there are errors in some template, won't this cause hard to read error messages when they're spit out at final end of compilation ? Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics
I read the disussion above and I'll post my thoughts so far below: - we'll use a syntax as close as possible to Chrome, e.g. type TList = class ... end; - 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; Maybe we need an exception to this when supporting sub routine templates: procedure p(mylist : TList); begin ... end; but this doesn't lead to an ambigious syntax. - instantiation steps which require code generation are done after main program compilation based on information saved in the unit files, this has some advantages: - several equal instantiations require only one specialisation - it's possible to setup an symbol environment as it has been used in the template definition, so the cyclic unit use problem is void it requires though that a lot symbols of the implementation part of a unit must be written to the unit file if the unit contains a template definition This approach will require some compiler clean ups but that isn't that bad ;) Any comments :)? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics
At 18:17 4-11-2005, you wrote: This is evaluated by the pre-compiler run during compile time. When you use the template with e.g. var bl: List; then procedure show(s:string) is taken. But what if the bl: List is called from an other unit? The Show(string) is then not visible anymore? Peter Vreman wrote: Mattias Gaertner wrote: This page looks only like the start of a proposal. Neither complete nor official. Why do you think, that D2006 will have generics? D2006 <> D11=D2007 How will Delphi handle the following case with overloads and different types: unit test; interface type List = class data : T; constructor(aData: T); procedure dump; end; implementation procedure show(i:integer);overload; begin end; procedure show(s:string);overload; begin end; constructor List(aData: T); begin Data := aData; end; procedure List.Dump; begin Show(Data); end; end. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel Peter ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics
This is evaluated by the pre-compiler run during compile time. When you use the template with e.g. var bl: List; then procedure show(s:string) is taken. Peter Vreman wrote: Mattias Gaertner wrote: This page looks only like the start of a proposal. Neither complete nor official. Why do you think, that D2006 will have generics? D2006 <> D11=D2007 How will Delphi handle the following case with overloads and different types: unit test; interface type List = class data : T; constructor(aData: T); procedure dump; end; implementation procedure show(i:integer);overload; begin end; procedure show(s:string);overload; begin end; constructor List(aData: T); begin Data := aData; end; procedure List.Dump; begin Show(Data); end; end. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics Syntax
> Peter Vreman wrote: >> Expiriment, feed g++ code with errors in the statements. With macro's >> those errors won't be show until the macro is used. But with templates >> this is diffent: > > Smart indeed :) > >> This is more important than the syntactical sugar. The rules where to >> declare generics and how/when they are parsed must be known. The syntax >> can be added in the end. > > Yes I understand, that's why I wanted to "invent" some syntax that's > useful but easier to implement than full-blown semi-macro stuff, I added: > > "Implementation of TGenericCollection can be compiled as if (T: > TCollectionItem) were used." > > This should mean the current parser for the implementation is good enough. > > "Would this solve the circular dependency ? It seems so to me, because > one knows at least as much as in current implementation of these > classes, but I'm no compiler engineer." > > And this should mean no 'weird' things can happen with > interface-implementation semi-cycles. > > Are more rules needed than these ? The interface-implementation things will still be there. At instanciation time the symbols are searched and not during the declaration of the generic type. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics Syntax
Peter Vreman wrote: Expiriment, feed g++ code with errors in the statements. With macro's those errors won't be show until the macro is used. But with templates this is diffent: Smart indeed :) This is more important than the syntactical sugar. The rules where to declare generics and how/when they are parsed must be known. The syntax can be added in the end. Yes I understand, that's why I wanted to "invent" some syntax that's useful but easier to implement than full-blown semi-macro stuff, I added: "Implementation of TGenericCollection can be compiled as if (T: TCollectionItem) were used." This should mean the current parser for the implementation is good enough. "Would this solve the circular dependency ? It seems so to me, because one knows at least as much as in current implementation of these classes, but I'm no compiler engineer." And this should mean no 'weird' things can happen with interface-implementation semi-cycles. Are more rules needed than these ? Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics
On Friday 04 November 2005 10:33, Vinzent Hoefler wrote: > On Friday 04 November 2005 09:25, Micha Nelissen wrote: > > Marc Weustink wrote: > > > If the generic is "pre"compiled (which is maybe necesary if you > > > need access to privates) then I fear some runtime logic has to be > > > added to call the correct procedure. IE. something like > > > > > > case TypeInfo(Data) of > > > StringType: Show(Data); > > > IntegerType: Show(Data); > > > end; > > > > The whole idea of Generics is to avoid this :-) > > At user level, yes. But as a compiler-writer you'd gotta make it work > somehow. Yes, "somehow", and not like that ;-) -- Regards, Christian Iversen ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics Syntax
> Peter Vreman wrote:
>> I did some tests with g++. It looks like it parses the template
>> 'normally'
>> and don't handle it like a macro. When instantiating the template the
>> generic type is replaced.
>
> What tests did you do to come to this conclusion ? I mean, how can one
> see how g++ parses things ?
Expiriment, feed g++ code with errors in the statements. With macro's
those errors won't be show until the macro is used. But with templates
this is diffent:
template class test
{
public:
T data;
string s;
int i;
void p()
{
show(data);
i=i*3+data+s; <--- this is allowed until instantiated
i=i*3+s;<--- this is not allowed
data=data;
}
};
>> full node tree when the generic is instantiated. But that means that it
>> must be known that
>
> ye? :-)
This is more important than the syntactical sugar. The rules where to
declare generics and how/when they are parsed must be known. The syntax
can be added in the end.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics Syntax
On Friday 04 November 2005 13:48, Vinzent Hoefler wrote: Stupid KMail. Deleted the text after file's eof. After the file there was supposed to be a remark about that the example does not compile as is, because generics in Ada are different from C++ templates, which are merely more like macros, but that it may give some ideas about the proposed syntax. Damn. I hate software. Vinzent. -- public key: http://www.t-domaingrabbing.ch/publickey.asc pgpO6hm6mmAZa.pgp Description: signature ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics Syntax
On Friday 04 November 2005 13:27, Marco van de Voort wrote:
["<>"]
> The evil is in
>
> - using characters instead of modifiers.
> - worse, recycling already used characters.
Alright, I completely understand at least the first part, so perhaps
they should simply not be overused. :-)
Just for the fun and for those who don't know it yet, the previously
given example in Ada95-syntax:
-- 8< -- snip --
procedure Gen_Test is
-
package Show is
procedure Do_It (i : Integer);
procedure Do_It (s : String);
end Show;
package body Show is
procedure Do_It (i : Integer) is
begin
null;
end Do_It;
procedure Do_It (s : String) is
begin
null;
end Do_It;
end Show;
-
-
generic
type T (<>) is private;
procedure Dump (Value : T);
procedure Dump (Value : T) is
use Show;
begin
Do_It (Value);
end Dump;
-
-
procedure My_Dump is new Dump (Integer);
procedure My_Dump is new Dump (String);
-
begin -- Gen_Test
My_Dump (42);
My_Dump ("foobar");
end Gen_Test;
pgp0x2VjCjF7F.pgp
Description: signature
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics Syntax
Peter Vreman wrote: I did some tests with g++. It looks like it parses the template 'normally' and don't handle it like a macro. When instantiating the template the generic type is replaced. What tests did you do to come to this conclusion ? I mean, how can one see how g++ parses things ? full node tree when the generic is instantiated. But that means that it must be known that ye? :-) Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics Syntax
> Micha Nelissen wrote: >> >> type >> TGenericCollection = generic(T: TCollectionItem) class(TComponent) >> ...implement TCollection and use T >> end; >> >> TCollection = TGenericCollection of (TCollectionItem); >> TFieldDefs = TGenericCollection of (TFieldDef); >> > > So generic procs could look like: > > > function generic(T: TTreeItem) MyFunc(A: T): T; > begin > // do something with the tree item > end; > > > My restrictions won't allow implementing generic Max and Min, I guess. > That really needs macro-alike stuff (for the compiler implementation). > The syntax could look like: > > > function generic(T) Max(A, B: T): T; > begin >if A < B then > Result := B >else > Result := A; > end; > I did some tests with g++. It looks like it parses the template 'normally' and don't handle it like a macro. When instantiating the template the generic type is replaced. I don't know if that is possible with FPC. The parser relies a lot on types being available. Writing a special parser for generics is possible. It can then store a simple expression/statement tree that will generate a full node tree when the generic is instantiated. But that means that it must be known that ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics Syntax
> types _at least_ in Ada's generics back in 1983[*] already. > Perhaps someone should take a look at those, because these are also > quite different from C++-templates. > > > Vinzent. > > [*] That would be the same year the term "C++" just appeared first in > history of programming languages then, and this particular C++ didn't > even have templates yet. The evil is in - using characters instead of modifiers. - worse, recycling already used characters. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics Syntax
Mattias Gaertner wrote: On Fri, 04 Nov 2005 13:44:55 +0100 Marc Weustink <[EMAIL PROTECTED]> wrote: Mattias Gaertner wrote: On Fri, 04 Nov 2005 10:47:42 +0100 Marc Weustink <[EMAIL PROTECTED]> wrote: Daniël Mantione wrote: Op Thu, 3 Nov 2005, schreef Mattias Gaertner: Here is a proposal of the syntax: type TGenericClass = class public procedure Add(Item: T; Flag: F); end; This syntax is almost impossible to implement since in one of your other >> mails the symbols to mark the parameters appear in regular source code: begin generictypeA.create end. It will be very hard for the parser to see the difference in advance between: variable symbol is parsed the result is known. Maybe the parser may be able lookup the type first and make a decision based on that, but it would be in the middle of a recursive expression parse designed for infix operators. Also in C++ this sometimes causes trouble where you need to change your code notation so the compiler eats it. I don't know if this proposal suffers from this mess, but we should avoid at all cost to import it into Pascal. On the wiki pages some of my remarks got lost (or I didn't write them down) but when I first looked at the <> notation style it looks very unpascalish for me. I like more to add a new keyword for it, like the samples wiht generic or template) BTW, what woud be the problem with type TMySpecificClass = TGenericClass(TObject, Integer); What about proc generics: GenericProc(TObject) This can be ambigious. How would you have declared the proc, and how do you call it. I don't see a problem yet. GenericProc(TObject)(some params) you mean ? Example: procedure MyProc(T); // generic procedure without parameters ver i: T; begin ... end; Therefor I propose it to use the generic keyword -> generic procedure MyProc(T); // generic procedure without parameters var i: T; begin ... end; procedure MyProc(T: TClass); // non generic procedure begin end; This should give a duplicate Identifier error. or when we usae a syntax similar Micha proposes (I changed the of): type TGenericProc = generic(T) of procedure(param, param) ... use T end; TObjectProc = TGenericProc(TObject) generic(T) procedure MyGenericProc(...) begin end; type TGenericCollection = generic(T: TCollectionItem) of class(TComponent) ...implement TCollection and use T end; TCollection = TGenericCollection(TCollectionItem); TFieldDefs = TGenericCollection(TFieldDef); And: type TGenericList = generic(T: PtrInt) of class(TObject) ...implement TList and use PtrInt size for code generation end; TList = TGenericList(Pointer); Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics Syntax
On Friday 04 November 2005 13:00, Micha Nelissen wrote: > Combining some of the wiki ideas, and has no "evil" <> characters > :-). I don't understand the fuzz about using "<>". It's not even close to being C(++)-ish, because it was used for describing discrete range types _at least_ in Ada's generics back in 1983[*] already. Perhaps someone should take a look at those, because these are also quite different from C++-templates. Vinzent. [*] That would be the same year the term "C++" just appeared first in history of programming languages then, and this particular C++ didn't even have templates yet. -- public key: http://www.t-domaingrabbing.ch/publickey.asc pgp3kje8Y8SWV.pgp Description: signature ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics Syntax
Micha Nelissen wrote: type TGenericCollection = generic(T: TCollectionItem) class(TComponent) ...implement TCollection and use T end; TCollection = TGenericCollection of (TCollectionItem); TFieldDefs = TGenericCollection of (TFieldDef); So generic procs could look like: function generic(T: TTreeItem) MyFunc(A: T): T; begin // do something with the tree item end; My restrictions won't allow implementing generic Max and Min, I guess. That really needs macro-alike stuff (for the compiler implementation). The syntax could look like: function generic(T) Max(A, B: T): T; begin if A < B then Result := B else Result := A; end; Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics Syntax
Ales Katona wrote: Example: procedure MyProc(T); // generic procedure without parameters ver i: T; begin ... end; procedure MyProc(T: TClass); // non generic procedure begin end; Call MyProc(TObject); What will happen? Mattias Sky will reign fire: procedure (var T); begin // generic or not?? end; So, just as with class procedures, we need an extra modifier. generic procedure (var T); begin // generic end; and procedure (var T); begin // not generic end; Vincent. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics Syntax
Ales Katona wrote: Are the () required? Why not TSomeList = TGenericList of Pointer; ? I guess, but in general one can use multiple generic types when coding a class, so this is to point out that it's ordered and defined. Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics Syntax
Ales Katona wrote: Micha Nelissen wrote: Marc Weustink wrote: BTW, what woud be the problem with type TMySpecificClass = TGenericClass(TObject, Integer); Or: type TGenericCollection = generic(T: TCollectionItem) class(TComponent) ...implement TCollection and use T end; TCollection = TGenericCollection of (TCollectionItem); TFieldDefs = TGenericCollection of (TFieldDef); And: type TGenericList = generic(T: PtrInt) class(TObject) ...implement TList and use PtrInt size for code generation end; TList = TGenericList of (Pointer); Combining some of the wiki ideas, and has no "evil" <> characters :-). Probably TFieldDefs adds functionality to TCollection, but it was first example I came up with. Implementation of TGenericCollection can be compiled as if (T: TCollectionItem) were used. Would this solve the circular dependency ? It seems so to me, because one knows at least as much as in current implementation of these classes, but I'm no compiler engineer. Micha Are the () required? Why not TSomeList = TGenericList of Pointer; ? You can have more types type TList = TGenericList of (Pointer, Pointer); Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics Syntax
Example: procedure MyProc(T); // generic procedure without parameters ver i: T; begin ... end; procedure MyProc(T: TClass); // non generic procedure begin end; Call MyProc(TObject); What will happen? Mattias Sky will reign fire: procedure (var T); begin // generic or not?? end; ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics Syntax
Micha Nelissen wrote: Marc Weustink wrote: BTW, what woud be the problem with type TMySpecificClass = TGenericClass(TObject, Integer); Or: type TGenericCollection = generic(T: TCollectionItem) class(TComponent) ...implement TCollection and use T end; TCollection = TGenericCollection of (TCollectionItem); TFieldDefs = TGenericCollection of (TFieldDef); And: type TGenericList = generic(T: PtrInt) class(TObject) ...implement TList and use PtrInt size for code generation end; TList = TGenericList of (Pointer); Combining some of the wiki ideas, and has no "evil" <> characters :-). Probably TFieldDefs adds functionality to TCollection, but it was first example I came up with. Implementation of TGenericCollection can be compiled as if (T: TCollectionItem) were used. Would this solve the circular dependency ? It seems so to me, because one knows at least as much as in current implementation of these classes, but I'm no compiler engineer. Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel Are the () required? Why not TSomeList = TGenericList of Pointer; ? Ales ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics Syntax
On Fri, 04 Nov 2005 13:44:55 +0100 Marc Weustink <[EMAIL PROTECTED]> wrote: > Mattias Gaertner wrote: > > On Fri, 04 Nov 2005 10:47:42 +0100 > > Marc Weustink <[EMAIL PROTECTED]> wrote: > > > > > >>Daniël Mantione wrote: > >> > >>>Op Thu, 3 Nov 2005, schreef Mattias Gaertner: > >>> > >>> > >>> > Here is a proposal of the syntax: > > type > TGenericClass = class > public > procedure Add(Item: T; Flag: F); > end; > >>> > >>> > >>>This syntax is almost impossible to implement since in one of your > >other >> > >>>mails the symbols to mark the parameters appear in regular source code: > >>> > >>>begin > >>> generictypeA.create > >>>end. > >>> > >>>It will be very hard for the parser to see the difference in advance > >>>between: > >>> > >>> variable >>> generic_type >>> > >>>Only when the > symbol is parsed the result is known. > >>> > >>>Maybe the parser may be able lookup the type first and make a decision > >>>based on that, but it would be in the middle of a recursive expression > >>>parse designed for infix operators. > >>> > >>>Also in C++ this sometimes causes trouble where you need to change your > > > >>>code notation so the compiler eats it. I don't know if this proposal > >>>suffers from this mess, but we should avoid at all cost to import it > >>>into Pascal. > >> > >>On the wiki pages some of my remarks got lost (or I didn't write them > >>down) but when I first looked at the <> notation style it looks very > >>unpascalish for me. I like more to add a new keyword for it, like the > >>samples wiht generic or template) > >> > >>BTW, > >>what woud be the problem with > >> > >>type > >> TMySpecificClass = TGenericClass(TObject, Integer); > > > > > > What about proc generics: > > > > GenericProc(TObject) > > > > This can be ambigious. > > How would you have declared the proc, and how do you call it. I don't > see a problem yet. > > GenericProc(TObject)(some params) you mean ? Example: procedure MyProc(T); // generic procedure without parameters ver i: T; begin ... end; procedure MyProc(T: TClass); // non generic procedure begin end; Call MyProc(TObject); What will happen? Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics Syntax
Marc Weustink wrote: BTW, what woud be the problem with type TMySpecificClass = TGenericClass(TObject, Integer); Or: type TGenericCollection = generic(T: TCollectionItem) class(TComponent) ...implement TCollection and use T end; TCollection = TGenericCollection of (TCollectionItem); TFieldDefs = TGenericCollection of (TFieldDef); And: type TGenericList = generic(T: PtrInt) class(TObject) ...implement TList and use PtrInt size for code generation end; TList = TGenericList of (Pointer); Combining some of the wiki ideas, and has no "evil" <> characters :-). Probably TFieldDefs adds functionality to TCollection, but it was first example I came up with. Implementation of TGenericCollection can be compiled as if (T: TCollectionItem) were used. Would this solve the circular dependency ? It seems so to me, because one knows at least as much as in current implementation of these classes, but I'm no compiler engineer. Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics Syntax
Mattias Gaertner wrote: On Fri, 04 Nov 2005 10:47:42 +0100 Marc Weustink <[EMAIL PROTECTED]> wrote: Daniël Mantione wrote: Op Thu, 3 Nov 2005, schreef Mattias Gaertner: Here is a proposal of the syntax: type TGenericClass = class public procedure Add(Item: T; Flag: F); end; This syntax is almost impossible to implement since in one of your other mails the symbols to mark the parameters appear in regular source code: begin generictypeA.create end. It will be very hard for the parser to see the difference in advance between: variable symbol is parsed the result is known. Maybe the parser may be able lookup the type first and make a decision based on that, but it would be in the middle of a recursive expression parse designed for infix operators. Also in C++ this sometimes causes trouble where you need to change your code notation so the compiler eats it. I don't know if this proposal suffers from this mess, but we should avoid at all cost to import it into Pascal. On the wiki pages some of my remarks got lost (or I didn't write them down) but when I first looked at the <> notation style it looks very unpascalish for me. I like more to add a new keyword for it, like the samples wiht generic or template) BTW, what woud be the problem with type TMySpecificClass = TGenericClass(TObject, Integer); What about proc generics: GenericProc(TObject) This can be ambigious. How would you have declared the proc, and how do you call it. I don't see a problem yet. GenericProc(TObject)(some params) you mean ? Marc var MSC: TMySpecificClass; begin MSC := TMySpecificClass.Create Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics
On Fri, 04 Nov 2005 08:38:03 +0100 [EMAIL PROTECTED] wrote: > Alexey Barkovoy wrote: > > >>> Delphi 11 .Net 2.0 will support Generics. Maybe Delphi 11 Win32. > >> > > > > > >> This page looks only like the start of a proposal. Neither complete nor > >> official. > >> Why do you think, that D2006 will have generics? > > > > > > Not Delphi 2006, but Delphi 2007 Thanks for the hint. Although the interesting question is: Will Delphi get generics this decade and how will they work? It seems, they want the same syntax as their C compilers and their .NET code. So, there is a good chance, that it will be the <> notation, which gives additional trouble for the parser. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics Syntax
On Fri, 04 Nov 2005 10:47:42 +0100 Marc Weustink <[EMAIL PROTECTED]> wrote: > Daniël Mantione wrote: > > > > Op Thu, 3 Nov 2005, schreef Mattias Gaertner: > > > > > >>Here is a proposal of the syntax: > >> > >>type > >> TGenericClass = class > >> public > >>procedure Add(Item: T; Flag: F); > >> end; > > > > > > This syntax is almost impossible to implement since in one of your other > > > > mails the symbols to mark the parameters appear in regular source code: > > > > begin > > generictypeA.create > > end. > > > > It will be very hard for the parser to see the difference in advance > > between: > > > > variable > generic_type > > > Only when the > symbol is parsed the result is known. > > > > Maybe the parser may be able lookup the type first and make a decision > > based on that, but it would be in the middle of a recursive expression > > parse designed for infix operators. > > > > Also in C++ this sometimes causes trouble where you need to change your > > code notation so the compiler eats it. I don't know if this proposal > > suffers from this mess, but we should avoid at all cost to import it > > into Pascal. > > On the wiki pages some of my remarks got lost (or I didn't write them > down) but when I first looked at the <> notation style it looks very > unpascalish for me. I like more to add a new keyword for it, like the > samples wiht generic or template) > > BTW, > what woud be the problem with > > type >TMySpecificClass = TGenericClass(TObject, Integer); What about proc generics: GenericProc(TObject) This can be ambigious. > var >MSC: TMySpecificClass; > > begin >MSC := TMySpecificClass.Create Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics
Marc Weustink wrote: Micha Nelissen wrote: Marc Weustink wrote: case TypeInfo(Data) of StringType: Show(Data); IntegerType: Show(Data); end; The whole idea of Generics is to avoid this :-) I mean generated by the compiler, not by the "user" I understand, but I would be rather disappointed if it were implemented like this. One might as well write a script rather than integrate it into the compiler; the thing the compiler could add is generate efficient *and* compact *and* typesafe code. Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics Syntax
Daniël Mantione wrote: > > Op Thu, 3 Nov 2005, schreef Mattias Gaertner: > > >>Here is a proposal of the syntax: >> >>type >> TGenericClass = class >> public >>procedure Add(Item: T; Flag: F); >> end; > > > This syntax is almost impossible to implement since in one of your other > mails the symbols to mark the parameters appear in regular source code: > > begin > generictypeA.create > end. > > It will be very hard for the parser to see the difference in advance > between: I wouldn't allow specialization in the procedure body. That's unpascalish, you can' do ((^char)(p))^:=#0; but you need to define a pchar in a type section and do pchar(p)^:=#0; By forbidding that we can come back to the < ... >. > > variable generic_type > Only when the > symbol is parsed the result is known. > > Maybe the parser may be able lookup the type first and make a decision > based on that, but it would be in the middle of a recursive expression > parse designed for infix operators. > > Also in C++ this sometimes causes trouble where you need to change your > code notation so the compiler eats it. I don't know if this proposal > suffers from this mess, but we should avoid at all cost to import it into > Pascal. > > Daniël > > > > > ___ > fpc-devel maillist - fpc-devel@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics Syntax
Daniël Mantione wrote: Op Thu, 3 Nov 2005, schreef Mattias Gaertner: Here is a proposal of the syntax: type TGenericClass = class public procedure Add(Item: T; Flag: F); end; This syntax is almost impossible to implement since in one of your other mails the symbols to mark the parameters appear in regular source code: begin generictypeA.create end. It will be very hard for the parser to see the difference in advance between: variable symbol is parsed the result is known. Maybe the parser may be able lookup the type first and make a decision based on that, but it would be in the middle of a recursive expression parse designed for infix operators. Also in C++ this sometimes causes trouble where you need to change your code notation so the compiler eats it. I don't know if this proposal suffers from this mess, but we should avoid at all cost to import it into Pascal. On the wiki pages some of my remarks got lost (or I didn't write them down) but when I first looked at the <> notation style it looks very unpascalish for me. I like more to add a new keyword for it, like the samples wiht generic or template) BTW, what woud be the problem with type TMySpecificClass = TGenericClass(TObject, Integer); var MSC: TMySpecificClass; begin MSC := TMySpecificClass.Create Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics
Peter Vreman wrote:
>>Mattias Gaertner wrote:
>>
>>
>>>This page looks only like the start of a proposal. Neither complete nor
>>>official.
>>>Why do you think, that D2006 will have generics?
>>>
>>>
>>>
>>
>>D2006 <> D11=D2007
>
>
> How will Delphi handle the following case with overloads and different types:
>
>
>
> unit test;
>
> interface
>
> type
> List = class
> data : T;
> constructor(aData: T);
> procedure dump;
> end;
>
> implementation
>
> procedure show(i:integer);overload;
> begin
> end;
>
> procedure show(s:string);overload;
> begin
> end;
>
> constructor List(aData: T);
> begin
> Data := aData;
> end;
>
> procedure List.Dump;
> begin
> Show(Data);
> end;
>
> end.
It will be eaten, but as soon as you instanziate with non-integer/non-string you
get an error, see also C++:
#include
using namespace std;
void show(int i)
{
}
void show(string s)
{
}
template class test
{
public:
T data;
void p()
{
show(data);
}
};
test mytest1;
test mytest2;
int main()
{
mytest1.p();
mytest2.p();
}
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics
On Friday 04 November 2005 09:25, Micha Nelissen wrote: > Marc Weustink wrote: > > > If the generic is "pre"compiled (which is maybe necesary if you > > need access to privates) then I fear some runtime logic has to be > > added to call the correct procedure. IE. something like > > > > case TypeInfo(Data) of > > StringType: Show(Data); > > IntegerType: Show(Data); > > end; > > The whole idea of Generics is to avoid this :-) At user level, yes. But as a compiler-writer you'd gotta make it work somehow. Vinzent. -- public key: http://www.t-domaingrabbing.ch/publickey.asc pgp8YjRx3wBer.pgp Description: signature ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics
Micha Nelissen wrote: Marc Weustink wrote: Peter Vreman wrote: How will Delphi handle the following case with overloads and different types: If the generic is "pre"compiled (which is maybe necesary if you need access to privates) then I fear some runtime logic has to be added to call the correct procedure. IE. something like case TypeInfo(Data) of StringType: Show(Data); IntegerType: Show(Data); end; The whole idea of Generics is to avoid this :-) I mean generated by the compiler, not by the "user" Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics
Peter Vreman wrote: How will Delphi handle the following case with overloads and different types: The restriction to use generic types only in (assignment to)/(passing to procedure) of the same generic type is too big a restriction ? If you want to do this, one should instantiate it first .. ? Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics
Marc Weustink wrote: Peter Vreman wrote: How will Delphi handle the following case with overloads and different types: If the generic is "pre"compiled (which is maybe necesary if you need access to privates) then I fear some runtime logic has to be added to call the correct procedure. IE. something like case TypeInfo(Data) of StringType: Show(Data); IntegerType: Show(Data); end; The whole idea of Generics is to avoid this :-) Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics
Peter Vreman wrote: Mattias Gaertner wrote: This page looks only like the start of a proposal. Neither complete nor official. Why do you think, that D2006 will have generics? D2006 <> D11=D2007 How will Delphi handle the following case with overloads and different types: If it is handled as a kind of macro, then it is no problem. The type of data is known at compile time. If the generic is "pre"compiled (which is maybe necesary if you need access to privates) then I fear some runtime logic has to be added to call the correct procedure. IE. something like case TypeInfo(Data) of StringType: Show(Data); IntegerType: Show(Data); end; Marc unit test; interface type List = class data : T; constructor(aData: T); procedure dump; end; implementation procedure show(i:integer);overload; begin end; procedure show(s:string);overload; begin end; constructor List(aData: T); begin Data := aData; end; procedure List.Dump; begin Show(Data); end; end. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics
> Mattias Gaertner wrote: > >>This page looks only like the start of a proposal. Neither complete nor >>official. >>Why do you think, that D2006 will have generics? >> >> >> > > D2006 <> D11=D2007 How will Delphi handle the following case with overloads and different types: unit test; interface type List = class data : T; constructor(aData: T); procedure dump; end; implementation procedure show(i:integer);overload; begin end; procedure show(s:string);overload; begin end; constructor List(aData: T); begin Data := aData; end; procedure List.Dump; begin Show(Data); end; end. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics
> Delphi 11 .Net 2.0 will support Generics. Maybe Delphi 11 Win32. > There is already proposal: > >http://qc.borland.com/wc/qcmain.aspx?d=11168 > > The FPC syntax must be at least a subset of the Borland syntax to be > compatible. Only if they are usuable for FPC. Delphi.NET has .NET 2.0 generics as target, which are a bit odd IIRC (only for types that can implement an interface, and _runtime_ (JIT) instantiation of the templtated code) FPC has native as focus. Let's not forget that. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics
Alexey Barkovoy wrote: Delphi 11 .Net 2.0 will support Generics. Maybe Delphi 11 Win32. This page looks only like the start of a proposal. Neither complete nor official. Why do you think, that D2006 will have generics? Not Delphi 2006, but Delphi 2007 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel Danny Thorpe's talk on Generics: http://bdntv.borland.com/replay/mp3/24%20Hours%20of%20DeXter%201020-1050.mp3 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics
Delphi 11 .Net 2.0 will support Generics. Maybe Delphi 11 Win32. This page looks only like the start of a proposal. Neither complete nor official. Why do you think, that D2006 will have generics? Not Delphi 2006, but Delphi 2007 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics
Mattias Gaertner wrote: This page looks only like the start of a proposal. Neither complete nor official. Why do you think, that D2006 will have generics? D2006 <> D11=D2007 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics
On Fri, 04 Nov 2005 01:06:42 +0100 [EMAIL PROTECTED] wrote: > Hi *, > Delphi 11 .Net 2.0 will support Generics. Maybe Delphi 11 Win32. > There is already proposal: > >http://qc.borland.com/wc/qcmain.aspx?d=11168 > > The FPC syntax must be at least a subset of the Borland syntax to be > compatible. This page looks only like the start of a proposal. Neither complete nor official. Why do you think, that D2006 will have generics? Mattias > > > > Mattias Gaertner wrote: > > >Hi all, > > > >I want to push generics to the next level. > >For those not familar, there is already a wiki about this topic: > > > >http://www.freepascal.org/wiki/index.php/Generics > > > >The page still contains a couple of different proposals, so I guess, the > >syntax is not yet defined. > >And there are still some unsolved problems, before we can start > >implementing it. > >My goal is to extend Lazarus first, so we can play with the new features, > >before extending the compiler, which is much more complicated. > > > >The syntax: > >The wiki contains a few proposals, but does not mention the > >advantages/disadvantages. So, here are some thoughts. Please comment and > >tell, where you see problems or a better solution. > > > >- Templates should work at least for: classes, classes of, interfaces, > >objects, records, pointers, procedures/functions. > >- Templates may also work for: procedure types > >- Template parameters can be any type. > >- Template parameters may be specialised (e.g. only) > > > > > >Mattias > >___ > >fpc-devel maillist - fpc-devel@lists.freepascal.org > >http://lists.freepascal.org/mailman/listinfo/fpc-devel > > > > > > > > > > > ___ > fpc-devel maillist - fpc-devel@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics
Hi *, Delphi 11 .Net 2.0 will support Generics. Maybe Delphi 11 Win32. There is already proposal: http://qc.borland.com/wc/qcmain.aspx?d=11168 The FPC syntax must be at least a subset of the Borland syntax to be compatible. Mattias Gaertner wrote: Hi all, I want to push generics to the next level. For those not familar, there is already a wiki about this topic: http://www.freepascal.org/wiki/index.php/Generics The page still contains a couple of different proposals, so I guess, the syntax is not yet defined. And there are still some unsolved problems, before we can start implementing it. My goal is to extend Lazarus first, so we can play with the new features, before extending the compiler, which is much more complicated. The syntax: The wiki contains a few proposals, but does not mention the advantages/disadvantages. So, here are some thoughts. Please comment and tell, where you see problems or a better solution. - Templates should work at least for: classes, classes of, interfaces, objects, records, pointers, procedures/functions. - Templates may also work for: procedure types - Template parameters can be any type. - Template parameters may be specialised (e.g. only) Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics Syntax
On Thu, 03 Nov 2005 22:35:34 +0100 Peter Vreman <[EMAIL PROTECTED]> wrote: > At 20:41 3-11-2005, you wrote: > >On Thu, 3 Nov 2005 20:25:07 +0100 (CET) > >Daniël Mantione <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > Op Thu, 3 Nov 2005, schreef Mattias Gaertner: > > > > > > > Right. I didn't think of that. > > > > > > > > What about edged brackets? > > > > > > > > type > > > > TGenericClass[T,F] = class > > > > public > > > > procedure Add(Item: T; Flag: F); > > > > end; > > > > > > At first sight it looks okay. If necessary it is possible to introduce > > > a two character bracket, i.e. (# #) or (! !), > > > >Hmm. Emoticons in Freepascal. Nice idea. > > > >(:T:) > > > > > > > or with whatever character you want as long as it is not a prefix or > > > postfix operator. > > > >Yes. As I said, I will implement it first in Lazarus, so we can see what > >it bites. > > The syntax is the easy part. Yes. But the WIKI was not even finished on this part. > How to parse the body of procedures of a > generic type is the crucial part. The normal pascal parser can't be used > because that requires knowledge of the types. > > The easiest way to implement generics are like macro's with parameters. Something like that I have in mind. My main goal is to reduce boring paste/copy/replace, not to moisten FPC. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics Syntax
At 20:41 3-11-2005, you wrote: On Thu, 3 Nov 2005 20:25:07 +0100 (CET) Daniël Mantione <[EMAIL PROTECTED]> wrote: > > > Op Thu, 3 Nov 2005, schreef Mattias Gaertner: > > > Right. I didn't think of that. > > > > What about edged brackets? > > > > type > > TGenericClass[T,F] = class > > public > > procedure Add(Item: T; Flag: F); > > end; > > At first sight it looks okay. If necessary it is possible to introduce a > two character bracket, i.e. (# #) or (! !), Hmm. Emoticons in Freepascal. Nice idea. (:T:) > or with whatever character you want as long as it is not a prefix or > postfix operator. Yes. As I said, I will implement it first in Lazarus, so we can see what it bites. The syntax is the easy part. How to parse the body of procedures of a generic type is the crucial part. The normal pascal parser can't be used because that requires knowledge of the types. The easiest way to implement generics are like macro's with parameters. Peter ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
