Re: [fpc-devel] language extensions
Michael Schnell wrote: We already have the generics can the preprocessor symbols. That leaves the "for in". The development team has its doubts about the "for in" construct, but: * Andreas did it in a reasonably clean way with a lot less hacks and ugly constructions than Delphi did. * The pressure on us is increasing to have a "for in". AFAIK, Chrome does extended "for in" or similar stuff. I'd vote for using a meta-compiler or other pre-processor instead. I think the preprocessor is already doing too much, and not in a very nice way. If we were to rewrite the preprocessor so that it wouldn't actually be a preprocessor, but a built-in meta-compile stage, that would be good. Then we could do strict syntax- and semantic checks on the preproc statements. Right now there are all kinds of errors that can happen in specific circumstances. -- Regards Christian Iversen (who actually worked on the fpc preproc) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] language extensions
We already have the generics can the preprocessor symbols. That leaves the "for in". The development team has its doubts about the "for in" construct, but: * Andreas did it in a reasonably clean way with a lot less hacks and ugly constructions than Delphi did. * The pressure on us is increasing to have a "for in". AFAIK, Chrome does extended "for in" or similar stuff. Case-string seems very handy in many cases and does not look like imposing problems. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] language extensions
Delphi supports iterator for the "for in" in different ways: * Dynamic arrays, static arrays, sets, strings and records have "built-in" iterators * For classes and interface it requires a method called "GetEnumerator". GetEnumerator can return a class, an interface or a record. This class, interface or record must have a member called "MoveNext" and a property called "Current". MoveNext returns a Boolean and Current returns the item. You can for example do the following with a dynamic array: type TDoubleArray = array of Double; var A : TDoubleArray; D : Double; begin A := TDoubleArray.Create(1.0, 2.1, 3.2); for D in A do Writeln(D); end; On 14/06/07, Bram Kuijvenhoven <[EMAIL PROTECTED]> wrote: Daniël Mantione wrote: > > Op Thu, 14 Jun 2007, schreef Florian Klaempfl: > >> Graeme Geldenhuys schrieb: >>> I like the "for-in" code. >> Using the default property is clean, using count imo not. Thought I >> admit I've no idea so far to do it better. > > Well, there already is a ";default;" directive, we could add a ";counter;" > directive. Something like that would be nice, but maybe an even nicer approach would be property Items[index:Integer] read GetItem write SetItem low GetLow high GetHigh; or (to be more friendly to legacy code parsers) property Items[index:Integer] read GetItem write SetItem; low GetLow; high GetHigh; Then you can use Low(object.Items) and High(object.Items), even Low(object) if Items is the default property. If you stick with the 'Count' concept, I'd opt for property Items[index:Integer] read GetItem write SetItem; count GetCount; property Items[index:Integer] read GetItem write SetItem; count FCount; Alternatives: property Items[index:Integer] read GetItem write SetItem; length GetLength; property Items[index:Integer] read GetItem write SetItem; size GetSize; To support properties that cannot be indexed by simple ordinals, an iterator mechanism could be added, like property Items[key:string]; iterator GetIterator; where GetIterator must return e.g. an IIterator interface, which is then to be defined in Objpas or the like, much like IUnkown. Add support for all this to the RTTI and you can even use it in streaming, scripting engines etc. Regards, Bram ___ 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] language extensions
Ales schrieb: > David Butler wrote / napísal(a): >> Actually, Delphi now supports "for-in". >> >> It also supports things like nested classes, class helpers, operator >> overloading and inlining. > All those features are because of .NET. > > FPC supported "proper" operator overloading (not in classes only) and > inlining for quite some time now. Nested classes are somewhat eluding me > I must admit... IIRC we enabled nested classes in 2.1.x too, at least nested types. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] language extensions
On 14/06/07, Bram Kuijvenhoven <[EMAIL PROTECTED]> wrote: Daniël Mantione wrote: > > Op Thu, 14 Jun 2007, schreef Florian Klaempfl: > >> Graeme Geldenhuys schrieb: >>> I like the "for-in" code. >> Using the default property is clean, using count imo not. Thought I >> admit I've no idea so far to do it better. > > Well, there already is a ";default;" directive, we could add a ";counter;" > directive. where GetIterator must return e.g. an IIterator interface, which is then to be defined in Objpas or the like, much like IUnkown. The iterator approach is the most neutral. It can be implemented for any type of structure, even those that do not necessarily have integer indexes. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] language extensions
Daniël Mantione wrote: Op Thu, 14 Jun 2007, schreef Florian Klaempfl: Graeme Geldenhuys schrieb: I like the "for-in" code. Using the default property is clean, using count imo not. Thought I admit I've no idea so far to do it better. Well, there already is a ";default;" directive, we could add a ";counter;" directive. Something like that would be nice, but maybe an even nicer approach would be property Items[index:Integer] read GetItem write SetItem low GetLow high GetHigh; or (to be more friendly to legacy code parsers) property Items[index:Integer] read GetItem write SetItem; low GetLow; high GetHigh; Then you can use Low(object.Items) and High(object.Items), even Low(object) if Items is the default property. If you stick with the 'Count' concept, I'd opt for property Items[index:Integer] read GetItem write SetItem; count GetCount; property Items[index:Integer] read GetItem write SetItem; count FCount; Alternatives: property Items[index:Integer] read GetItem write SetItem; length GetLength; property Items[index:Integer] read GetItem write SetItem; size GetSize; To support properties that cannot be indexed by simple ordinals, an iterator mechanism could be added, like property Items[key:string]; iterator GetIterator; where GetIterator must return e.g. an IIterator interface, which is then to be defined in Objpas or the like, much like IUnkown. Add support for all this to the RTTI and you can even use it in streaming, scripting engines etc. Regards, Bram ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] language extensions
David Butler wrote / napísal(a): > > > All the same, they are also supported in the Win32 compiler. What I ment to say is that we're most probably not going to re-do what we already have done differently before Delphi. eg: I don't see their OOP "operator overloading" as viable considering we have a proper one. The other syntax sugar stuff can be done for mode delphi I guess. > > > > ___ > 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] language extensions
On 14/06/07, Ales( Katona <[EMAIL PROTECTED]> wrote: David Butler wrote / napísal(a): > Actually, Delphi now supports "for-in". > > It also supports things like nested classes, class helpers, operator > overloading and inlining. All those features are because of .NET. All the same, they are also supported in the Win32 compiler. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] language extensions
David Butler wrote / napísal(a): > Actually, Delphi now supports "for-in". > > It also supports things like nested classes, class helpers, operator > overloading and inlining. All those features are because of .NET. FPC supported "proper" operator overloading (not in classes only) and inlining for quite some time now. Nested classes are somewhat eluding me I must admit... > > See: > > http://dn.codegear.com/article/34324 > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] language extensions
Op Thu, 14 Jun 2007, schreef Florian Klaempfl: > Graeme Geldenhuys schrieb: > > Hi, > > > > I found this website containing language extension that Andreas > > Hausladen wrote for Delphi. > > > > Is there possibly something we can use in Free Pascal? Sorry, I'm not > > sure what license Andreas used. > > > > http://andy.jgknet.de/dlang/ > > I like the idea of making generics an extra section. Maybe we should > think about to do it the same way in fpc. > > > > > I like the "for-in" code. > > Using the default property is clean, using count imo not. Thought I > admit I've no idea so far to do it better. Well, there already is a ";default;" directive, we could add a ";counter;" directive. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] language extensions
Actually, Delphi now supports "for-in". It also supports things like nested classes, class helpers, operator overloading and inlining. See: http://dn.codegear.com/article/34324 On 14/06/07, Florian Klaempfl <[EMAIL PROTECTED]> wrote: Graeme Geldenhuys schrieb: > Hi, > > I found this website containing language extension that Andreas > Hausladen wrote for Delphi. > > Is there possibly something we can use in Free Pascal? Sorry, I'm not > sure what license Andreas used. > > http://andy.jgknet.de/dlang/ I like the idea of making generics an extra section. Maybe we should think about to do it the same way in fpc. > > I like the "for-in" code. Using the default property is clean, using count imo not. Thought I admit I've no idea so far to do it better. ___ 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] language extensions
Graeme Geldenhuys schrieb: > Hi, > > I found this website containing language extension that Andreas > Hausladen wrote for Delphi. > > Is there possibly something we can use in Free Pascal? Sorry, I'm not > sure what license Andreas used. > > http://andy.jgknet.de/dlang/ I like the idea of making generics an extra section. Maybe we should think about to do it the same way in fpc. > > I like the "for-in" code. Using the default property is clean, using count imo not. Thought I admit I've no idea so far to do it better. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] language extensions
Vinzent Hoefler schrieb: > On Thursday 14 June 2007 06:42, Florian Klaempfl wrote: > >> Why do you need a plug in mechanism? You've the sources? When you >> have the sources, 90 per cent of the use of a plugin are gone. > > Well, we'd call that non-intrusive change. ;) > > You'd just need to compile the plug-in, and not a changed compiler > (which then may even apply recursively). This rules out a whole class > of possible error sources. > > So it's probably the last 10% that counts. ;) Which, BTW, fits nicely > into another 90/10 rule: 90% of all errors are coming from only 10% of > the code. ;) And the last 10% require 90% of the work i.e. adding a plugin interface. This rules out plugins :) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] language extensions
On Thursday 14 June 2007 06:42, Florian Klaempfl wrote: > Why do you need a plug in mechanism? You've the sources? When you > have the sources, 90 per cent of the use of a plugin are gone. Well, we'd call that non-intrusive change. ;) You'd just need to compile the plug-in, and not a changed compiler (which then may even apply recursively). This rules out a whole class of possible error sources. So it's probably the last 10% that counts. ;) Which, BTW, fits nicely into another 90/10 rule: 90% of all errors are coming from only 10% of the code. ;) Vinzent. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] language extensions
Op Thu, 14 Jun 2007, schreef Graeme Geldenhuys: > On 13/06/07, Daniël Mantione <[EMAIL PROTECTED]> wrote: > > > > Andreas uses a preprocessor to convert the language extensions into > > Delphi > > compatible code. This is a remarkable achievement, but I don't see much > > value for this approach for Free Pascal; since we have the source code, > > we > > could implement the features directly. > > I didn't mean the way he did it, I meant the language features he > added. Would there be anything useful (language features) we could > add the the Free Pascal Compiler? We already have the generics can the preprocessor symbols. That leaves the "for in". The development team has its doubts about the "for in" construct, but: * Andreas did it in a reasonably clean way with a lot less hacks and ugly constructions than Delphi did. * The pressure on us is increasing to have a "for in". I'm not totally happy with the hardcoded method names Andreas used, but his implementation could be used as a base to build on. > I just thought we could discuss some language ideas/improvements and > add them to Mantis feature requests or something. I think a Wiki article per improved suggestion is better, so every one can comment on it. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] language extensions
On 13/06/07, Daniël Mantione <[EMAIL PROTECTED]> wrote: Andreas uses a preprocessor to convert the language extensions into Delphi compatible code. This is a remarkable achievement, but I don't see much value for this approach for Free Pascal; since we have the source code, we could implement the features directly. I didn't mean the way he did it, I meant the language features he added. Would there be anything useful (language features) we could add the the Free Pascal Compiler? I just thought we could discuss some language ideas/improvements and add them to Mantis feature requests or something. Graeme. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] language extensions
Neil Graham schrieb: > Daniël Mantione wrote: >> Andreas uses a preprocessor to convert the language extensions into >> Delphi compatible code. This is a remarkable achievement, but I don't >> see much value for this approach for Free Pascal; since we have the >> source code, we could implement the features directly. >> > I think it's good to do things like this as a preprocessor(when > possible) initially. It means ideas can be > tried out more easily and given a test run before attacking the compiler. > > I guess it could be done in the compiler if someone made a plugin > mechanism for fpc. Why do you need a plug in mechanism? You've the sources? When you have the sources, 90 per cent of the use of a plugin are gone. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] language extensions
Daniël Mantione wrote: Andreas uses a preprocessor to convert the language extensions into Delphi compatible code. This is a remarkable achievement, but I don't see much value for this approach for Free Pascal; since we have the source code, we could implement the features directly. I think it's good to do things like this as a preprocessor(when possible) initially. It means ideas can be tried out more easily and given a test run before attacking the compiler. I guess it could be done in the compiler if someone made a plugin mechanism for fpc. I ain't volunteering for _that_ job :-) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] language extensions
Op Wed, 13 Jun 2007, schreef Graeme Geldenhuys: > Hi, > > I found this website containing language extension that Andreas > Hausladen wrote for Delphi. > > Is there possibly something we can use in Free Pascal? Sorry, I'm not > sure what license Andreas used. > > http://andy.jgknet.de/dlang/ > > I like the "for-in" code. Andreas uses a preprocessor to convert the language extensions into Delphi compatible code. This is a remarkable achievement, but I don't see much value for this approach for Free Pascal; since we have the source code, we could implement the features directly. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
