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

Here is a proposal of the syntax:

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;

I think, the parameters should be at the identifier name, not in the class block, because that's the way you use them:

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

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
  generictypeA<integer>.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: TGenericList<integer>;
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 = TGenericList<integer>;

Mattias

Op Thu, 3 Nov 2005, schreef Mattias Gaertner:

This syntax is almost impossible to implement since in one of your other mails the symbols to mark the parameters appear in regular source code:

begin
  generictypeA<integer>.create
end.

It will be very hard for the parser to see the difference in advance between:

variable<integer(another_var)
generic_type<integer

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

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

Op Thu, 3 Nov 2005, schreef Mattias Gaertner:

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

And a proposal for bounding:

  TGenericClass[T: TComponent] = class end;

Mattias

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

The syntax is the easy part. How to parse the body of procedures of a generic type is the crucial part. The normal pascal parser can't be used because that requires knowledge of the types.

The easiest way to implement generics are like macro's with parameters.

Peter

Yes. But the WIKI was not even finished on this part.

Something like that I have in mind.
My main goal is to reduce boring paste/copy/replace, not to moisten FPC.

Mattias

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

D2006 D11=D2007

> 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

Danny Thorpe's talk on Generics:
http://bdntv.borland.com/replay/mp3/24%20Hours%20of%20DeXter%201020-1050.mp3

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.

How will Delphi handle the following case with overloads and different types:

unit test;
interface
type
  List<T> = class
    data : T;
    constructor(aData: T);
    procedure dump;
  end;
implementation
procedure show(i:integer);overload;
begin
end;
procedure show(s:string);overload;
begin
end;
constructor List<T>(aData: T);
begin
  Data := aData;
end;
procedure List<T>.Dump;
begin
  Show(Data);
end;
end.

If it is handled as a kind of macro, then it is no problem. The type of data is known at compile time.
If the generic is "pre"compiled (which is maybe necesary if you need access to privates) then I fear some runtime logic has to be added to call the correct procedure. IE. something like

   case TypeInfo(Data) of
     StringType: Show(Data);
     IntegerType: Show(Data);
   end;

Marc

The whole idea of Generics is to avoid this :-)

Micha

I mean generated by the compiler, not by the "user"

Marc

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

At user level, yes. But as a compiler-writer you'd gotta make it work somehow.

Vinzent.

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)
{
}

template<typename T> class test
{
public:

    T data;
    void p()
    {
      show(data);
    }

};

test<int> mytest1;
test<int *> mytest2;

int main()
{

  mytest1.p();
  mytest2.p();

}

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

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

I understand, but I would be rather disappointed if it were implemented like this. One might as well write a script rather than integrate it into the compiler; the thing the compiler could add is generate efficient *and* compact *and* typesafe code.

Micha

What about proc generics:

GenericProc(TObject)

This can be ambigious.

Mattias

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

How would you have declared the proc, and how do you call it. I don't see a problem yet.

GenericProc(TObject)(some params) you mean ?

Marc

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

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

Are the () required? Why not TSomeList = TGenericList of Pointer; ?

Ales

Sky will reign fire:

procedure (var T);
begin
  // generic or not??
end;

You can have more types
<code>
type

   TList = TGenericList of (Pointer, Pointer);

</code>

Marc

Ales Katona wrote

Are the () required? Why not TSomeList = TGenericList of Pointer; ?

I guess, but in general one can use multiple generic types when coding a class, so this is to point out that it's ordered and defined.

Micha

So, just as with class procedures, we need an extra modifier.

generic procedure (var T);
begin
// generic
end;
and
procedure (var T);
begin
// not generic
end;

Vincent.

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

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.

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

The evil is in

- using characters instead of modifiers.
- worse, recycling already used characters.

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

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;

Peter Vreman wrote

I did some tests with g++. It looks like it parses the template 'normally' and don't handle it like a macro. When instantiating the template the generic type is replaced.

What tests did you do to come to this conclusion ? I mean, how can one see how g++ parses things ?

full node tree when the generic is instantiated. But that means that it must be known that

....yessss? :-)

Micha

On Friday 04 November 2005 13:48, Vinzent Hoefler wrote:

Stupid KMail. Deleted the text after file's eof.

After the file there was supposed to be a remark about that the example does not compile as is, because generics in Ada are different from C++ templates, which are merely more like macros, but that it may give some ideas about the proposed syntax.

Damn. I hate software.

Vinzent.

Expiriment, feed g++ code with errors in the statements. With macro's those errors won't be show until the macro is used. But with templates this is diffent:

template<typename T> class test
{
public:

    T data;
    string s;
    int i;
    void p()
    {
      show(data);
      i=i*3+data+s;   <--- this is allowed until instantiated
      i=i*3+s;        <--- this is not allowed
      data=data;
    }

};

> full node tree when the generic is instantiated. But that means that it > must be known that ....yessss? :-)

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, "somehow", and not like that ;-)

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

The interface-implementation things will still be there. At instanciation time the symbols are searched and not during the declaration of the generic type.

This is evaluated by the pre-compiler run during compile time.

When you use the template with e.g.

var
 bl: List<String>;

then procedure show(s:string) is taken.

But what if the bl: List<String> is called from an other unit? The Show(string) is then not visible anymore?

Peter

I read the disussion above and I'll post my thoughts so far below:

- we'll use a syntax as close as possible to Chrome, e.g. type
TList<T> = class
...

  end;

- instantiation will be only possible in declaration blocks, not in code
blocks:
possible:
var
  mylist : TList<integer>;
const
  mylist : TList<integer> = nil;
type
  mylist = TList<integer>;
forbidden:
procedure p(mylist : TList<integer>);
begin
  ...
  mylist:=TList<integer>.create;
  ...
end;
Maybe we need an exception to this when supporting sub routine templates:
procedure<T> p(mylist : TList<T>);
begin
...
end;
but this doesn't lead to an ambigious syntax.

- instantiation steps which require code generation are done after main program compilation based on information saved in the unit files, this has some advantages:
- several equal instantiations require only one specialisation
- it's possible to setup an symbol environment as it has been used in the template definition, so the cyclic unit use problem is void it requires though that a lot symbols of the implementation part of a unit must be written to the unit file if the unit contains a template definition

This approach will require some compiler clean ups but that isn't that bad ;)

Any comments :)?

- 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

Hi,

hmm.. a parameter declaration of a function declaration is not a declaration block ? I've always thought of them like local variables, just happening to be pre-filled..

and, will TList<integer> and mylist be compatible types ?

you mean to save the parse tree of the generic (both the interface and the implementation section) to the ppu ? I've been thinking about using a extra file in order not to taint the ppu but if it is possible to use the ppu itself for that, i'm all for it :)

- several equal instantiations require only one specialisation

- it's possible to setup an symbol environment as it has been used in the template definition, so the cyclic unit use problem is void it requires though that a lot symbols of the implementation part of a unit must be written to the unit file if the unit contains a template definition

note that line number information for nice error messages need to be retained along with the parse tree of the generic (so that when another unit uses a generic unit but specializes it to something stupid, programmer gets a nice location of error rather than "guess where it was" :)).
Maybe it already is done, though :)

Note that for the error message, you'll need _two_ locations: one of the generic type implementation where the actual error manifested and one for the location of the specialization of the generic, to know what has been used as the type parameter.

On second though, _maybe_ just one location (the first) and the names of the types used for the type parameters suffice.

cheers,
Danny

dannym wrote

hmm.. a parameter declaration of a function declaration is not a declaration block ? I've always thought of them like local variables, just happening to be pre-filled..

procedure p(a : array[0..10] of longint);

isn't possible either.

Inlining does this already, the infrastructure is in place.

For Inlining this works too.

What is Chrome? Some examples of Generics:

http://www.remobjects.com/articles/?id={A1D08EE3-0D9E-4828-AFB3-B2C1E772186E}

Hi! I've been following the generic discussion with great interest. Here are some of my thoughts.

I greatly favor this syntaxis above the generic-modifier. It will look at a lot more familiar to most programmers (due to e.g. C++ and Java), is more compact and moreover likely to be compatible with other implementations (Chrome, rumors about Delphi 11).

I assume this also means that the generic type identifier has to be included in the method implementation, e.g.

TList<T>.Add(AValue: T);
  begin
    ...
  end;

This would also allow overloading of generics, i.e. having (generic) classes with different numbers of type parameters, but the same name. E.g. having both a TList and a TList<T>. (though a declaration like TList = TList<pointer> could easily solve this in this case)

How will we deal with restrictions on the type of a generic parameter? Chrome does this with for example

  Dictionary<Key, 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.

TList<T>.Add(AValue: T);
  ...
TList<T: 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.

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.

Because you can easily decide that a T following a < in the code is a generic parameter? (I assume you also allow TList<T>.Create in the code block ... above?)

- instantiation steps which require code generation are done after main program compilation based on information saved in the unit files, this has some advantages: - several equal instantiations require only one specialisation

So TList<TSomeNiceObkect> and TList<TSomeOtherNiceObject> share the same code if nothing particular of the types TSomeNiceObject and TSomeOtherNiceObject is used in the generic?

That is indeed quite important I think. Container classes often do not assume anything about the class they store, and otherwise we would get a lot of duplicate code in the resulting executables (for all different classes, which in fact all are 4 (or 8) byte pointers).

- it's possible to setup an symbol environment as it has been used in the template definition, so the cyclic unit use problem is void it requires though that a lot symbols of the implementation part of a unit must be written to the unit file if the unit contains a template definition

Will a generic implementation have access to procedures visible at the location where the generic is instantiated? It might seem at first to be a useful restriction to disallow this, because otherwise a TList<TMyType> in unit1 could need another specialisation than TList<MyType> in unit2. But on the other hand, we might just want to allow it! Example:

In the (imaginary) unit containers there might be a TSortedList<T> class, which uses the < operator on T. In yourunit you define a type TYourType and an operator < operating on TYourType. If you now want use TSortedList<TYourType> in yourunit, it will need to pick up the operator defined in yourunit, which is not visible in the unit containers.

Similar questions might arise with respect to code for Hashing a specific type for e.g. THashMap<Key, 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

The token-lookahead is a hack and will create more problems and performance loss in a critical part of the compiler.

The restriction of type blocks only is not strange at all, Delphi allows 'class of' is also only in type blocks

Ok, I didn't know it would be a real ugly hack. And you are right about the 'class of'. It is in fact very similar, as we can extend the conventions regarding naming as follows:

type
  TMyObject = class ... end;
  TMyObjectClass = class of TMyObject;
  TMyObjectList = TList<TMyObject>;
  TMyObjectSet = TSet<TMyObject>;
  TStringMyObjectMap = TMap<string, 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

"Must look familiar" programmers should be fired.

is more compact

Pascal is about *readability* !

and moreover likely to be compatible with other implementations (Chrome, rumors about Delphi 11).

Leave the rumors to rest. And who uses Chrome anyway ? :-P

Micha

Ok, I didn't know it would be a real ugly hack. And you are right about the 'class of'. It is in fact very similar, as we can extend the conventions regarding naming as follows:

type
 TMyObject = class ... end;
 TMyObjectClass = class of TMyObject;
 TMyObjectList = TList<TMyObject>;
 TMyObjectSet = TSet<TMyObject>;
 TStringMyObjectMap = TMap<string, 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

Correct. Pascal tools usually do. (and I heard GCC4 C++ is also RD)

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

Micha Nelissen wrote: Consider for example the following: Is Java bad because it looks like C++?

No. But it inherits from C syntax in nearly all forms.

The test is consistency. Java is consistent if it follows C(++) syntax, (the rest of the language is C(++) like), (free)pascal not,

Or is PHP bad because is looks like C++?

Most scripting languages are basically historical amalgam of syntaxes, which is also why they are not very suitable to write very large programs.

FPC is a general purpose language, which should be suitable to write large programs. This requires some orthogonality of syntax, to make the errorrate (due to syntax) as low as possible.

The problem is that all langs you list are C derivates. At least on the syntax level (e.g. {} for blocks, semicolon as statement terminator etc)

I think if other considerations tie, we should therefore choose for as well. I think this will at least add to popularity and also reduce RSI ;)

I won't speak out in favour or against here. I did this several times in syntax discussions with Peter (and Florian/Jonas/Daniel too) before, and he was always right.

One simply can't say do "this" up front, but really has to look into (or know) the insides of the language to be able to predict if a change could be ambiguous, and avoid loosing consistency of the language.

Does for generics fit into Pascal? Well, we use [] for array indexing, and () for parameter passing to procedures/functions/methods. So why not use for passing parameters to generic types? And, similar to the case of function calls and array indexing, these could follow the type identifier directly.

You got a point here, but the "where T is Foo" stuff is crap then, don't you agree?

TGType<T: TBaseType> = class(...) ... end;

is better then, when compared to your parameter example.

Micha

I indeed don't like the "where T is foo" of Chrome :) So you are totally right, TGType<T : TBaseType> is a lot better and a lot more consistent (with e.g. function parameter syntaxis).

Bram

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

Personally, I also think that a keyword is in order, just as for 'Operator'. 'Generic' is the obvious choice. Something like

 TMyGenericClass = Generic Class (Ancestor,TemplateName)
 end;

etc. the (,,,) syntax is used for interfaces as well, so that isn't too horrible.

I think < > is an ugly C++ hack, and I would very much regret seeing the beautyful Object Pascal language butchered by such things.

Michael.

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.

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 second this proposal. But I _don't_ think that this is a minor detail. One of the nice things about (Object) Pascal is the readability. The does away with that.

Michael.

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

No, as I said, we should allow template instantiation only in type blocks.

- makes the parser more difficult and slow

See above.

- makes pascal more ambigious

See above.

- alternatives: modifiers or not yet used brackets like (! !) or (# #)

Ugly :)

type
  TMyType = boolean(a<b)..(a>b);

:)

Sure. But some people like emoticons. !)

Ok. So, FPC will follow chrome/Delphi?

Mattias

Well, that's no problem either, the compiler knows that the < for parameter instantiation can only follow types being templates/generics :) Parsing is usually type driven in fpc.

I would do so, see my mail from the weekend :)

Well generics *are* a kind of "parameterised" type. When you choose types for the parameters, then the type is fully defined, just like the result of a not-with-outside-interacting procedure would be when it's parameters are filled in. When you view it this way, Bram has a point.

I am still a proponent of a keyword btw, which I've documented at wiki:

http://www.freepascal.org/wiki/index.php/Generics#Terms

(just scroll a little upwards). This is because it generalizes better to function generics, I think that in "Max<T: TSomeType>(Foo: Type): T" the last T feels "out-of-scope", while it doesn't when you have the generic keyword because you're defining a "function generic(T) ..."

Of course, these are all minor details compared to actual implementation.

Micha

[...] > Ok. So, FPC will follow chrome/Delphi? I would do so, see my mail from the weekend :)

I see, but also I see all the other posts still discussing the syntax. I wondered, if it was definitive.

Mattias

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

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 us, native is the core platform, and how they twist themselves to achieve compat between .NET and win32 (and how much .NET syntax they borrow) is not our problem.

Exactly.
That is why I prefer a more 'object pascal' syntax, and not this preprocessor-like stuff.

Later on, the -MDelphi switch can be used to implement delphi-compatible parsing. If they do it differently from chrome, then we'll implement -MChrome...

Michael.

I don't see any relation between FPC and Chrome.

Non trivial Chrome code won't ever run under FPC and vice versa. (at the very least string indexing is 0 based under Chrome, but IIRC constructor and destructor behaviour also)

I know Chrome is .NET oriented Delphians pet peeve, but compability wise it is irrelevant. It is only interesting for Delphians that really leave delphi(.net) behind, but then C# is a choice as well.

Marco van de Voort wrote

I know Chrome is .NET oriented Delphians pet peeve, but compability wise it is irrelevant. It is only interesting for Delphians that really leave delphi(.net) behind, but then C# is a choice as well.

So what you're saying is Chrome is only used by people who hate Borland and hate Microsoft but still want .NET (for it's GC and library, I assume) ? :-)

Is Chrome not language (backward) compatible to Delphi.NET ? (I don't know Chrome that well.) I mean, if so, then people cannot migrate from Delphi.NET to Chrome ... so I wonder how many people are using it then ?

Micha

Roughly. I'd say
- they don't want C# because they are scared of C syntax.
- they don't like Delphi.NET because it is less Delphi.NET due to its win32 compat.

Afaik a very small group. Everybody seems to experiment with chrome, but I hear only few people that actually use it. (and that means that uptake is really low, since even Delphi.NET is that popular, a lot of .NETties directly move to MS VS tools)

Is Chrome not language (backward) compatible to Delphi.NET ? (I don't know Chrome that well.)

Afaik, no. Chrome is not frpm Borland.

I mean, if so, then people cannot migrate from Delphi.NET to Chrome ... so I wonder how many people are using it then ?

I know none that use it for production use. All people that use Delphi.NET seem to play with it, but I can't remember definite crossovers.

Hi,

Put the Show(string) into the ppu too, with a mangled name, and save any calls of Show within the generic type implementation to the ppu, writing the mangled name.

Excuse the stupid made-up example below, but I can't think of anything that really _needs_ global functions right now, so I cheated by using class functions and a global catch-all variable to require a global translation function:

unit ubaz;
interface
type
  TCache = generic(T: TObject) class(TObject)
  published
    class procedure Put(Name: string; Instance: T);
    class function Get(Name: string): T;
  end;
implementation
var
  gCachedObjects: array of TObject;
  gCachedNames: array of string;
function FooToBar(Name: string; Instance: TObject): string;
begin
  Result := T.ClassName + '_' + Name;
end;
class procedure TCache.Put(Name: string; Instance: T);
begin
  SetLength(gCachedObjects, Length(gCachedObjects) + 1);
  SetLength(gCachedNames, Length(gCachedNames) + 1);
  gCachedObjects[High(gCachedObjects)] := Instance;
  gCachedNames[High(gCachedNames)] := FooToBar(Name, Instance);
end;
class function TCache.Get(Name: string): T;
var
  i: Integer;
begin
  Result := nil;
  for i := 0 to High(gCachedNames) do begin
    if gCachedNames[i] = Name then begin
      if gCachedObjects[i] is T then begin
        Result := gCachedObjects[i];
      end;
      Break;
    end;
  end;
end;
end.

the generated ppu should have

$Private$FooToBar$string$TObject: function ($2843423)

  and the generic parts:
    ....
    gCachedNames[High(gCachedNames)] := uBaz.$Private$FooToBar(Name,
Instance);

Or did I miss something important ? (apart from the act of auto-publishing of the function although it is not in the interface section being a bit evil)

cheers,
Danny

[...]

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.

Delphi incompatibility is a NoGo for FPC.

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.

Marco van de Voort wrote: > Delphi incompatibility is a NoGo for FPC.

LOL.

Then they have to publish their specs real soon now. And I mean not something in a blog, but more something like documentation. We can't wait another 5 years, until they finally make up their mind.

Vincent

Generics are already standardized. According to Borland, the Win32 Gernerics syntax will be a subset of the .Net sytanx.

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.

ECMA Standard 334

In Delphi 2007. Delphi.Net Generics syntax is defined by the .Net syntax.

If they don't, the syntax is still open.

And I was thinking there is no .Net syntax, since .Net is available for a wide range of languages with different syntaxes.

Or maybe I don't know the meaning of the word syntax.

Vincent.

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

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.

Why should Borland reinvent the wheel?
http://bdn.borland.com/article/0,1410,33383,00.html

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

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.

I have tried to organize the "usage example" section a bit, I think most of the "(uncategorized)" items can be removed now (authors of respective pieces: please do clean up if possible, or reply here if it's really new/adds something).

Also, for the sake of it, I added a Vote page:

http://www.freepascal.org/wiki/index.php/Generics_Vote

Pro reason will probably be: "compatibility".
Pro "generic" will probably be: more Pascal-alike/readability.

Micha

I'd really like to vote, but refuse to log in.
I've had to re-think of a username and password already way too much for this wiki.

So feel free to add my name under 'pro generic' if you want to count my vote ;-)

Michael.

Delphi.Net2.0 is using
Chrome is using
C# is using
C/C++ is using

Why should FPC use "generics" ???

That b.s. will break the Delphi code base!

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.

Why should FPC be Pascal-ish? Is that your question? :-)

mm

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

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

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

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

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;