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.

Regards,
- Graeme -

Op Wed, 13 Jun 2007, schreef Graeme Geldenhuys:

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

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 :-)

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.

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.

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.

Op Thu, 14 Jun 2007, schreef Graeme Geldenhuys:

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

And the last 10% require 90% of the work i.e. adding a plugin interface. This rules out plugins :)

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.

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

Op Thu, 14 Jun 2007, schreef Florian Klaempfl:

Well, there already is a ";default;" directive, we could add a ";counter;" directive.

Daniël

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...

All the same, they are also supported in the Win32 compiler.

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.

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

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.

IIRC we enabled nested classes in 2.1.x too, at least nested types.

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;

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

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.