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
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; 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
[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
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
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
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: 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
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
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
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: 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
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
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, 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
[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: 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
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 TListT = 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. TListT.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 TListT. (though a declaration like TList = TListpointer 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 DictionaryKey, Value = public class where Key is IComparable, Key has constructor, Value is Component; And will it be possible to have type dependent specializations? E.g. TListT.Add(AValue: T); ... TListT: TObject.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 : TListinteger; const mylist : TListinteger = nil; type mylist = TListinteger; forbidden: procedure p(mylist : TListinteger); begin ... mylist:=TListinteger.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: procedureT p(mylist : TListT); 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 TListT.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 TListTSomeNiceObkect and TListTSomeOtherNiceObject 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 TListTMyType in unit1 could need another specialisation than TListMyType in unit2. But on the other hand, we might just want to allow it! Example: In the (imaginary) unit containers there might be a TSortedListT 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 TSortedListTYourType 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. THashMapKey, Value. 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 -
Re: [fpc-devel] Templates / Generics
- instantiation will be only possible in declaration blocks, not in code blocks: possible: var mylist : TListinteger; const mylist : TListinteger = nil; type mylist = TListinteger; forbidden: procedure p(mylist : TListinteger); begin ... mylist:=TListinteger.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
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 = TListTMyObject; TMyObjectSet = TSetTMyObject; TStringMyObjectMap = TMapstring, TMyObject; 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
Micha Nelissen wrote: Bram Kuijvenhoven wrote: Florian Klaempfl wrote: - we'll use a syntax as close as possible to Chrome, e.g. type TListT = 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
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? TGTypeT: TBaseType = 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: 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? TGTypeT: TBaseType = 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, TGTypeT : TBaseType 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 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? TGTypeT: TBaseType = 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, TGTypeT : TBaseType 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
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 TListT = 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
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? TGTypeT: TBaseType = 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, TGTypeT : TBaseType 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)..(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 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
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 = TListTMyObject; TMyObjectSet = TSetTMyObject; TStringMyObjectMap = TMapstring, TMyObject; 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
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
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 ListT = 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 ListT(aData: T); begin Data := aData; end; procedure ListT.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
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 precompiled (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 ListT = 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 ListT(aData: T); begin Data := aData; end; procedure ListT.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
Marc Weustink wrote: Peter Vreman wrote: How will Delphi handle the following case with overloads and different types: If the generic is precompiled (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: 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
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 precompiled (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
On Friday 04 November 2005 09:25, Micha Nelissen wrote: Marc Weustink wrote: If the generic is precompiled (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
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
ListT = 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 ListT(aData: T);
begin
Data := aData;
end;
procedure ListT.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 string
using namespace std;
void show(int i)
{
}
void show(string s)
{
}
templatetypename T class test
{
public:
T data;
void p()
{
show(data);
}
};
testint mytest1;
testint * 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 Syntax
Daniël Mantione wrote: Op Thu, 3 Nov 2005, schreef Mattias Gaertner: Here is a proposal of the syntax: type TGenericClassT,F = 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 generictypeAinteger.create end. It will be very hard for the parser to see the difference in advance between: variableinteger(another_var) generic_typeinteger 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); 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 Syntax
Daniël Mantione wrote: Op Thu, 3 Nov 2005, schreef Mattias Gaertner: Here is a proposal of the syntax: type TGenericClassT,F = 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 generictypeAinteger.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 ... . variableinteger(another_var) generic_typeinteger 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
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 TGenericClassT,F = 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 generictypeAinteger.create end. It will be very hard for the parser to see the difference in advance between: variableinteger(another_var) generic_typeinteger 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
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
Marc Weustink wrote: BTW, what woud be the problem with type TMySpecificClass = TGenericClass(TObject, Integer); Or: code type TGenericCollection = generic(T: TCollectionItem) class(TComponent) ...implement TCollection and use T end; TCollection = TGenericCollection of (TCollectionItem); TFieldDefs = TGenericCollection of (TFieldDef); /code And: code type TGenericList = generic(T: PtrInt) class(TObject) ...implement TList and use PtrInt size for code generation end; TList = TGenericList of (Pointer); /code 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
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 TGenericClassT,F = 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 generictypeAinteger.create end. It will be very hard for the parser to see the difference in advance between: variableinteger(another_var) generic_typeinteger 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
Micha Nelissen wrote: Marc Weustink wrote: BTW, what woud be the problem with type TMySpecificClass = TGenericClass(TObject, Integer); Or: code type TGenericCollection = generic(T: TCollectionItem) class(TComponent) ...implement TCollection and use T end; TCollection = TGenericCollection of (TCollectionItem); TFieldDefs = TGenericCollection of (TFieldDef); /code And: code type TGenericList = generic(T: PtrInt) class(TObject) ...implement TList and use PtrInt size for code generation end; TList = TGenericList of (Pointer); /code 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
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
Ales Katona wrote: Micha Nelissen wrote: Marc Weustink wrote: BTW, what woud be the problem with type TMySpecificClass = TGenericClass(TObject, Integer); Or: code type TGenericCollection = generic(T: TCollectionItem) class(TComponent) ...implement TCollection and use T end; TCollection = TGenericCollection of (TCollectionItem); TFieldDefs = TGenericCollection of (TFieldDef); /code And: code type TGenericList = generic(T: PtrInt) class(TObject) ...implement TList and use PtrInt size for code generation end; TList = TGenericList of (Pointer); /code 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 code type TList = TGenericList of (Pointer, Pointer); /code Marc ___ 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: code type TGenericCollection = generic(T: TCollectionItem) class(TComponent) ...implement TCollection and use T end; TCollection = TGenericCollection of (TCollectionItem); TFieldDefs = TGenericCollection of (TFieldDef); /code So generic procs could look like: code function generic(T: TTreeItem) MyFunc(A: T): T; begin // do something with the tree item end; /code 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: code function generic(T) Max(A, B: T): T; begin if A B then Result := B else Result := A; end; /code Micha ___ 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
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 TGenericClassT,F = 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 generictypeAinteger.create end. It will be very hard for the parser to see the difference in advance between: variableinteger(another_var) generic_typeinteger 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; 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): code type TGenericProc = generic(T) of procedure(param, param) ... use T end; TObjectProc = TGenericProc(TObject) generic(T) procedure MyGenericProc(...) begin end; /code code type TGenericCollection = generic(T: TCollectionItem) of class(TComponent) ...implement TCollection and use T end; TCollection = TGenericCollection(TCollectionItem); TFieldDefs = TGenericCollection(TFieldDef); /code And: code type TGenericList = generic(T: PtrInt) of class(TObject) ...implement TList and use PtrInt size for code generation end; TList = TGenericList(Pointer); /code Marc ___ 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
Micha Nelissen wrote: code type TGenericCollection = generic(T: TCollectionItem) class(TComponent) ...implement TCollection and use T end; TCollection = TGenericCollection of (TCollectionItem); TFieldDefs = TGenericCollection of (TFieldDef); /code So generic procs could look like: code function generic(T: TTreeItem) MyFunc(A: T): T; begin // do something with the tree item end; /code 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: code function generic(T) Max(A, B: T): T; begin if A B then Result := B else Result := A; end; /code 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
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
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 precompiled (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: 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
This is evaluated by the pre-compiler run during compile time. When you use the template with e.g. var bl: ListString; 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 ListT = 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 ListT(aData: T); begin Data := aData; end; procedure ListT.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
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: ListString; then procedure show(s:string) is taken. But what if the bl: ListString 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 ListT = 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 ListT(aData: T); begin Data := aData; end; procedure ListT.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
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
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 Problems
There are some unsolved problems of generics in free pascal: 1. See wiki: http://www.freepascal.org/wiki/index.php/Generics#Notes The generic should not use private parts of a unit: interface generictype declar implementation procedure helper; begin end constructor generictype.create begin helper end end. IMO this can be allowed. But maybe it is a problem for the compiler? 2. Circle dependencies: unit a; interface generictypeA implementation uses B end. unit b; interface uses a implemenation begin generictypeAinteger.create end. Same: a problem for the compiler? 3. Name space. The unit, where the template is defined, has different uses clauses, than the unit, where the template is declared. In which order are the units searched? a) Ignore uses clause of template unit b) First uses clause of template unit, then uses clause of using unit. c) ? 4. Automatic generic parameters: var List: TGenericListinteger; begin List:=TGenericList.Create; // Note: ^ missing integer end; I'm against automatic generic parameters. I don't even like the generic declaration without a type name. I would only allow named types: type TListOfInteger = TGenericListinteger; Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics Syntax
On Thu, 3 Nov 2005 19:59:40 +0100 (CET) Daniël Mantione [EMAIL PROTECTED] wrote: Op Thu, 3 Nov 2005, schreef Mattias Gaertner: Here is a proposal of the syntax: type TGenericClassT,F = 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 generictypeAinteger.create end. It will be very hard for the parser to see the difference in advance between: variableinteger(another_var) generic_typeinteger 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. Right. I didn't think of that. What about edged brackets? type TGenericClass[T,F] = class public procedure Add(Item: T; Flag: F); end; procedure TGenericClass.Add(Item: T; Flag: F); // Note: No redundant [T,F] after TGenericClass. begin end; type TListOfComponent = TGenericList[TComponent]; Analog: type TGenericListClass[T] = class of TGenericList[T]; type PGenericRecord[T] = ^TGenericRecord[T]; procedure GenericProc[T](Param: T); begin end; Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics Syntax
On Thu, 3 Nov 2005 20:10:35 +0100 Mattias Gaertner [EMAIL PROTECTED] wrote: On Thu, 3 Nov 2005 19:59:40 +0100 (CET) Daniël Mantione [EMAIL PROTECTED] wrote: Op Thu, 3 Nov 2005, schreef Mattias Gaertner: Here is a proposal of the syntax: type TGenericClassT,F = 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 generictypeAinteger.create end. It will be very hard for the parser to see the difference in advance between: variableinteger(another_var) generic_typeinteger 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. Right. I didn't think of that. What about edged brackets? type TGenericClass[T,F] = class public procedure Add(Item: T; Flag: F); end; procedure TGenericClass.Add(Item: T; Flag: F); // Note: No redundant [T,F] after TGenericClass. begin end; type TListOfComponent = TGenericList[TComponent]; Analog: type TGenericListClass[T] = class of TGenericList[T]; type PGenericRecord[T] = ^TGenericRecord[T]; procedure GenericProc[T](Param: T); begin end; And a proposal for bounding: TGenericClass[T: TComponent] = class end; Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics Syntax
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 (! !), or with whatever character you want as long as it is not a prefix or postfix operator. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics Syntax
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. Mattias ___ 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
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
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
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
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
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. 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
