Hi,

I'm wondering why Pascal as a language (and FPC with it's extensions) does not support va_args (or var_args in the java language).

Now we have open array, that's a really cool thing, but I can't understand why I can't have a feature such as the compiler voodoo magic of the "write" procedure.

At the moment, I try to create an OS (it's hard to even think of it as one at the moment, it will take a lot of time until it will be something close to an OS) with FPC, and when compiling the system unit again, I really missing it, and open arrays are just not "that" ...

I can give a list of pros about it, but I rather hear the pros and the cons from other first (maybe me and others will accept it) so what are the cons you see about it, and are there any pros that might be able to make it possible to add such feature to FPC ?

Ido

Op Mon, 2 Oct 2006, schreef ik:

Hi, I'm wondering why Pascal as a language (and FPC with it's extensions) does not support va_args (or var_args in the java language).

It does: array of const. If you declare a procedure cdecl it is even binary compatible with a C varargs.

Now we have open array, that's a really cool thing, but I can't understand why I can't have a feature such as the compiler voodoo magic of the "write" procedure.

Syntactically you cannot. However, the array of const is just as powerfull (actually more powerfull, since you can pass multiple arrays). We consider adding a trick to make it syntactically behave like writeln unnecessary.

Show the problem with array if const first :)

Daniël

But in vtype I can't know if I got array or not, and I can't know if that's a record. :(

Lets start from the pity ones to the real problems :)

1. It's not a va_args.
2. The usage of [].
3. Even empty parameter must have [] instead of not calling it. It's like C that must have empty () when calling a function ...
4. I can't add default values to that type of parameter.
5. Feel like an hack.
6. Try to explain that to a C developer... it easier to bash your head against the wall
7. Require delphi/objfpc modes.
8. Have a record inside that tells you the type of the parameter (that is also a pro as much as it con)
9. I feel like it limiting the type of usage I can do with it because it support only "basic" types of parameters (according to the example in the documentation:
http://www.freepascal.org/docs-html/ref/refsu47.html#x113-12000010.3.6).
10. I feel that there is not enough documentation about it.

(Hey I promised some pity reasons ;))

There might be probably more reasons why not to use open arrays, but I can't think on more at the moment.

Daniël

Ido

Op Mon, 2 Oct 2006, schreef ik:

No, but you can pass a pointer to them. That simply wouldn't fit, i.e. blow up the size of the record. You can't pass arrays or records in C either, right?

Well, you can get it enabled in fpc mode if want. For the rest, it was exactly the intention to invent a safe mechanism that doesn't allow you to destroy your stack with a simple typo.

If we would code a variable number of parameters, that will only be a syntactic alternative for the same construction.

Daniël

You can't in C either. C varargs everything is "if string and arguments match it won't crash".

So? Other language, other syntax. We don't use {} either.

2. The usage of [].

Same. Penalty for being safe. It is also required being able to mix non array of const and normal parameters.

3. Even empty parameter must have [] instead of not calling it. It's like C that must have empty () when calling a function ...

C has no checking what so ever, we want to do better.

4. I can't add default values to that type of parameter.

Can you in C?

5. Feel like an hack.

Where do you get that feeling?

6. Try to explain that to a C developer... it easier to bash your head against the wall

Then don't do it. Let the C runtime solve his interface problem for him, and only provide (2) calls.

7. Require delphi/objfpc modes.

So? It is higher level functionality.

8. Have a record inside that tells you the type of the parameter (that is also a pro as much as it con)

Only on the inside. Your application programmer won't notice this.

9. I feel like it limiting the type of usage I can do with it because it support only "basic" types of parameters (according to the example in the documentation: http://www.freepascal.org/docs-html/ref/refsu47.html#x113-12000010.3.6).

You can pass any class, and, after verifying it is a class, further discriminate using object.classtype and/or is/as operators

10. I feel that there is not enough documentation about it.

Look for "Essential Pascal".

There might be probably more reasons why not to use open arrays, but I can't think on more at the moment.

Basically all are "it is not both C and Java". Well, it isn't. It is FPC/Delphi.

Even if you want to make a comparison, make one, and then also list the disadvantages of the solution (like the horrible security model of C, or the runtime overhead of Java)

Sure you do, {$include file.inc} {$H+} {Comment} We just don't use it as the C syntax wishes ...

What is the difference ? I mean, what is the difference between fnc(a,b,c,d,e,f,g,h,i,j);
and
fnc(a,[bcdefghij]);
?

On both cases I can add 0..n amount of variables ... but ", , , , , ," without [] imho is more intuitive. I don't need to know how the parameters where implemented inside the function.. I need only to know how to use the function ...

Think on lets say a function name "Init", it tells me that it initialize something, it does not tell me how it initialize it... now if I'll call it "InitbyObject" will tell me that it uses Object to initialize things.

The [] is the same as "InitbyObject". It's informative, but not really needed.

Cool, but if you want to do better, then lets get one step further and say that nil value does not need to be "0 amount of values" in the parameter usage itself. Why not just to check

if (not openarray = nil) then ...

?

> 4. I can't add default values to that type of parameter. Can you in C?

No, but Pascal is better then C imho ... :) and as long as we have "var", "const" or "value" we should have default value (if we wish) imho ...

Lets say I wish to have the following procedure:

Writeln

Now even if I do not have any value inside, I want a value to print, lets say #0, why should I start making "if" and checks to see the length of the openarray, when I can just "print" the value for example.

> 5. Feel like an hack. Where do you get that feeling?

"OK, so I don't have a way to make a compiler voodoo magic, but I can use an open array to get the closer feeling", but as Daniel say, in order to complete the usage of such thing, I need a synthetic sugar, and that does not implemented... It does not feel native ... it feels like a patch/hack that was added to shout people up when they say "you do not have var args".

Well I'm going soon to raise my presentation in a Linux club (I still have to have an answer from the organisers of two of that Linux clubs), and one of the questions that someone will ask (actually tease) on many unsupported things... now try to face such questions that you can not escape from ... I can't answer such teasing when I think someone is right ... :(

> 7. Require delphi/objfpc modes. So? It is higher level functionality.

So, if I do not need OOP, I must do an overloading of fnc(a :..) ..
fnc (a,b :..) ..
fnc (a,b,c : ..) ..
fnc (a,b,c,d : ...) ..

I think there is a function like this in the FPC core source. That's makes Pascal useless on such types of needs :( Or as someone told me "if you don't like this, just use C instead" . And that's not an answer I like to hear ... (when everything else fails, use assembly, not C! ;))

Back in the Delphi2-3 days (maybe its till exists), there was a hack that if a variable is from a range of 000000..111111 it is an integer, if the range of the memory is 222222..333333 the variable is float, if it's AAAAAA..FFFFFF it's a class etc.. you don't expect any developer to go that law to know such things ... specially, that it is not a constant thing on every OS and arch .

So how good are we then the C developers, that pointers are like air to them, even on places no other language really needs them (including c++) ?

"Maybe we should use object like variable types ?" (don't even bother to answer, I don't want such a thing)

Yes, but while most C compilers does not fully support K&R syntax and supports, and uses a lot of hacks and "patches like" ways to do things, we the Pascal developers, are better, smarter (ahmmm most of you ;)), and can solve things in a much different way then the C developers. But still some problems better solved in C then in Pascal (such as the synthetic usage of var_args).

Java is a way too clean and too resource consuming language to begin with. But Java 1.5 added a lot of things that many Java developers were crying to have for a lot of time...
People working to add support for generics for FPC alto you do not have a standard for it. FPC added a lot of support that is not added by any other modern Pascal compiler out there. But here we have something that I know of many people that actually will need it. Even if they don't know it yet, the second it will be out, they will use it, and will not understand why it wasn't implemented before, or how did they manage things before.

Even if you want to make a comparison, make one, and then also list the disadvantages of the solution (like the horrible security model of C, or the runtime overhead of Java)

I don't want a C or Java like compiler, I want that people from C or Java will find out that Pascal is able to do things, they can only dream on, and they will try to take it for themself.

Ours is not only bigger, but also better (on most things, but it's not perfect :( )

Ido

Op Mon, 2 Oct 2006, schreef ik:

It is fnc(a,[b,c,d,d,e,f,g,h,i,j]).

But let's separate the syntactic issue from the functionality:

* Syntactically, both methods can be safe.
* Syntactically, the FPC/Delphi one is more powerfull.
* Functionally, the C method is not safe, while the FPC/Delphi one is.
* Functionally, the FPC/Delphi method has more runtime overhead than the C one.

The [] is the same as "InitbyObject". It's informative, but not really needed.

The [] is the mechanism that allows you to pass multiple arrays.

Huh, I don't understand this?

Well, if it were to the Free Pascal developers, there would be no default values at all :) We heavily grumbled when we had to implement it to be Delphi compatible.

I don't understand this either.

On the contrary. I think we can consider constant arrays native? Then there is nothing about bad about reusing the principle. IMHO. Feel free to differ, but I consider the [] solution much more elegant than the C varargs.

Let me show you a very elegant use of the FPC language. We'll be implementing a printf style thing, but nicer:

type   help_type=type string;
operator :=(s:string):help_type;
begin
  result:=help_type(s);
end;
operator :=(s:longint):help_type;
begin
  val(s,result);
end;
procedure printf_improved(const s:string;args:array of help_type);

{This will format a string like 'We have $1 apples and $2 pears' and print it.}

begin
  {...}
end;
function localized_strings(var format,colour,thing:string);
begin
  if language=english then
    begin
      format:='A $1 $2';
      colour:='red';
      thing:='wine';
    end;
  if language=italiano then
    begin
      format:='Un $2 $1';  {In Italian the subject comes first.}
      colour:='vino';
      thing:='rosso';
    end;
end;
var format,colour,thing:string;
begin
  printf_improved('We have $1 apples and $2 pears',[1,5]);
  printf_improved('The value of variable b is',[b]);
  localized_strings(format,colour,thing);
  printf_improved(format,[colour,thing]);
end.

Now this example has many advantages over the C printf:
* It is type safe.
* It doesn't pull in unnecessary code into the executable, for example the boolean print code does not appear into the exe if we do not need it.
* The parameters can swap positions, so it is much more powerfull for translations.

Can you do this with C? I fear not. Show it to a C programmer and he'll be convinced Pascal has some amazingly powerfull features.

Actually I agree with you here.

Huh?!! Again I am lost.

I don't think there is an alternative here. If you would pass an array of pointers, you would get into trouble when passing integers. (Pascal is type safe.) Record variants are the only sensible solution.

This is exactly what we thought when coding this.

Sure! Just accept that sometimes things will work differently than in C, Pascal is not C, even if it is at least as powerfull.

Daniël

Well, I think that this is also a functional thing.

* Syntactically, both methods can be safe. * Syntactically, the FPC/Delphi one is more powerfull.

Well take a look at the way Java implement it:

.... function varrags(String ... a)
{
for (int i = 0; i<= a.length; i++)
{
a[i] ...
}
}

varags(a,b,c,d,e,f,g);

The thing I wish that you'll see is that here it's pure array like in Pascal, but the array is part of the content of the function and not part of the parameter usage ... (I can btw also use different types, so we solve the problem of unsafe types).

BTW in perl every group of scalars are actually an array... there is no difference .

I don't understand what you mean :(

If I will not add any parameter, I could check inside the function if the parameter is initilized rather then checking for length, so [] will be for 0 items while, no "[]" will be no parameters at all.

But we can see how good and helpful it is and can accept it :)

With an integer parameter, you can place "0" for example as default parameter, so with open array, you could also place default paramters, when #0 was just an example for that.

Yes and no, it is more elegant, but with few prices ...

Finally :) What does it take to make it non object oriented thingy, that is, it can be used on $MODE FPC ?

I'd seen hacks to find what is the parameter type (in delphi), by getting the memory address of that paramter, and the position inside a range of memory that the parameter located at, reprisent the type of that parameter.

I do not like variants. They are very memory weasting type, and most of the time operator overloading might make a better job.

But sometimes you can take things and make them better. I coded a lot in perl and recently I started coding in ruby, and I have expirence with a lot of other script based languages (like Java, nasl and more). Every time someone try to make a more "perfect" language, the solution looks more like a Pascal solution (even by syntax), rather then C and C++ like solution ...

In my language there is a saying of "the show makers always walk barefoot naked", why don't we make this a false sentence for Pascal ?

Daniël

Ido

I hope it was obvious that I meant blocks.

The type of a is secure in the second part, and it is faster. Keep in mind that more elaborate syntax increases the chance of copying/referencecount changing etc etc.

E.g. the standard example is printf. There the first type must be a string according to C, and this is (hopefully) enforced.

On both cases I can add 0..n amount of variables ... but ", , , , , ," without [] imho is more intuitive.

That's because of C mindset, and C mindset alone. What about parameters AFTER the varargs that are definite in type?

{$mode delphi}
procedure x(a:integer;b:array of const;c:integer);
begin
end;
var a ,b,c,d,e : Integer;
begin
  x(a,[b,c,d],e);
end.

Because that forces by reference and dynamic memory allocation. We don't want to become Java either. Again, there are possibilities with sane reasons between C and Java.

In theory there could. I don't really see thet use, since the procedure can detect that no other params are following

procedure x(a:array of const);
begin
  if high(a)>3  then
    begin
     param4:=1;
     param5:=2;
    end;
end;

Also note that this works with trailing parameters too (since they don't count in high())

Now even if I do not have any value inside, I want a value to print, lets say #0, why should I start making "if" and checks to see the length of the openarray, when I can just "print" the value for example.

No need to have a default. Just a rule that writeln([]) is equivalent to writeln;.

However for that see the FAQ about new features, and specially the part about inventing syntax to save a few keystrokes.

No it isn't. It is more. The need is real, but there was no need to keep it similar to C's 1970 syntax that was invented to keep the compiler in 20kwords.

There are already several differences:
1 non array of const parameters can follow the array of const 2 typesafety.
3 middle road performance wise. (a sacrifice for (2))

What's next, people on Windows to implement the whole of VB syntax, because that is the dominant languag there?

Moreover you probably stepped over the Daniel's mentioning that cdecl'ed array of const is varargs like.

But that is not what varargs is. Varargs just end pretty much any checking of the variant parts. And for interfacing we support somewhat it as cdecled

I think there is a function like this in the FPC core source. That's makes Pascal useless on such types of needs :( Or as someone

No it does not. Don't confuse the subject. It means a C programmer will have to learn a bit of two. I don't think this is a bad situation.

told me "if you don't like this, just use C instead" .

I think it is the other way around. You should say "if you don't like it, you should Pascal instead?"

That is just kidding. Seriously, don't take the whining to seriously. The next thing they want will be macro's etc etc.

If you will grant them every wish, better start using C immediately, since nothing else will satisfy them (and you pay the price in safety and productivity, not them !)

That's why Delphi/FPC learned from the C trap, and used the constants, so you won't need these hacks.

You can't teach a rock to dance. C is about as smart as a rock, higher level concepts are totally alien to it. array of const;cdecl; is limited, unsafe, and a natural fit for C.

Then give an example. I still haven't heard a real reason (let alone that it is reason enough). We already confirmed that you can be fully equal to C (array of const;cdecl);. What else can we do? Provide C header files that provide va_start macro's?

Java is a way too clean and too resource consuming language to begin with. But Java 1.5 added a lot of things that many Java developers were crying to have for a lot of time...

And probably rejected ten times as much proposals that didn't make it. And a lot of the changes involve coming down from the ivory tower.

People working to add support for generics for FPC alto you do not have a standard for it. FPC added a lot of support that is not added by any other modern Pascal compiler out there.

True. I never said we don't do extensions. There even is a faq entry about doing extensions, and I'll summarize it here:
- must make something possible not doable otherwise, not just be shorthand.
- fit in with the scope of the language.

But here we have something that I know of many people that actually will need it. Even if they don't know it yet, the second it will be out, they will use it, and will not understand why it wasn't implemented before, or how did they manage things before.

To be honest, I still don't have a clue what you still need over array of const;cdecl. However if I would develop an OS, I'd force array of const semantics on programmers, on all calls except the ones the language wants old-skool, and I'd overload even those with array of const, and find some clever synthesis functions/macro's for them.

I meant that we are using things for different usage. We do have blocks, we have begin end
we have try finally/except end (I have also remarks on those but not for this discussion).

And for some usages we have [] and () blocks as well.

The thing is we have blocks.

I agree here, but as I said (I hope), you need some sort of compiler directive to enable such thing. By default it should accept only []. I agree with that. And as I said before, this is a petty thing only.

I agree here for 100% with the need for [], and I understand the power it gives, but I still think that we should have a choice here.

But we can learn from C and we can learn from Java. BTW STL as far as I know (I don't know a lot of things regarding STL) try (and maybe did) solve this problems.

There is no need for default values for scalars as well, because we can add their value inside the function, but still sometimes it can help you.

Last time I checked VB is more dominant language then delphi and other languages. But the response is not correct.
For example, I do not like the fact in VB that I must use "," without parameter if I "don't' want to use" this parameters. This is a bad practice, but if you find it important, I will accept the fact that you need it, alto I will not agree with it.

Why is it so important for you that it will not be implemented ? I still do not understand your point of view... sorry :(

Moreover you probably stepped over the Daniel's mentioning that cdecl'ed array of const is varargs like.

I didn't stepped over... I also found that you have directive called "vararg" that I can place... but that is not the point, and I didn't had anything to say about it (no pro or con, so I didn't talked about it).

varargs allow me to add unknown amount of parameters without overloading a function with 500 calling to answer all the 500 parameters i might need.

It's not a bad situation to have 500 functions with all the possible parameters I might need ?

The person who told that is a Pascal developer .. and last time I checked we do have macro and even operator overloads. Oh and also the implementation of += -= i++ etc... too late :)

If you will grant them every wish, better start using C immediately, since nothing else will satisfy them (and you pay the price in safety and productivity, not them !)

"If you show the other side that you have problems they win" I never agreed with that point of view ... There is a difference between a need for something to make better and easier work, between "look ma, I can access the system by spinning all over the place".

But people can build houses from rocks, so they think that only rocks can create houses. If you want to teach people how to create houses with other materials, you need to show them first that you can create it with rocks, and show them something better after that imho...

But this support only exists for object oriented usage in the mode of Delphi and OBJFPC, I find it helpful to have it also in FPC mode !

I also see the need to make it even better, by making it more flexible that I can do things depends on my needs, instead of the place i am at.

You never know what's going on under the sun ... But still they added generics, and now there are smarter containers. They fixed a lot of bad ways to do things, and Java is more used the Pascal ...

What is not possible in making open array more flexible and make it work in more modes then Delphi and ObjFPC ?

- fit in with the scope of the language.

I don't understand why it does not belong to that ... :(

You are more then welcome to help me doing so :) You can start by creating exception handler for a kernel, so I could enter OBJFPC ... (My "OS" try to be pure 64 bit)

Ido

Op Mon, 2 Oct 2006, schreef ik:

You can have an array with a multitude of types in Java, but in Pascal this is not possible in Pascal. I.e. translating it to Pascal could be:

1  procedure varargs(a:...);
2
3  begin
4    for i:=low(a) to high(a) do
5      writeln(a[i]);
6  end;
7
8  begin
9   varargs(0.0,@varargs,[1,2,3],true);
10 end.

In Pascal the combination of line 5 and line 9 is unacceptable. We are a strongly typed language with static types. C can accept it because it is type unsafe. Java can accept it because the types are determined at runtime, with a big speed penalty of course.

A variant record is the proper solution. If you expect numbers, you access the Vinteger field. Expect a boolean? Use the Vboolean field. As a bonus, you can check the types of the parameters passed, and check them at runtime for extra safety.

> BTW in perl every group of scalars are actually an array... there is > no difference .

Perl has no static typing.

Multiple arrays is not possible in C:

procedure write_list_row(const fields:array of string;const widths:array of byte);
begin
  assert(high(fields)=high(widths);
  for i:=low(fields) to high(fields)
    writeln(fields[i]:widths[i]);
end;
begin
  write_list_row(['Language','Strong/weak','dynamic/static'],[20,15,15]);
  write_list_row(['Pascal','strong','static'],[20,15,15]);
  write_list_row(['C','weak','static'],[20,15,15]);
  write_list_row(['Java','strong','dynamic'],[20,15,15]);
end;

This can be achieved thanks to the [].

that in "procecure x(y:byte)" variable y is mandatory, there is no way you can pass nothing.

No, it sucks big time, IMHO. It is one the VB things Borland should not have put into Delphi. We've always had the opinion that an overload is the proper solution.

> With an integer parameter, you can place "0" for example as default > parameter, so with open array, you could also place default paramters, > when #0 was just an example for that.

Sure, we can implement that. But we are no fans of default parameters, and you have to stop somewhere, i.e. you want to avoid people putting complete constant record definitions in a procedure header. Simple types only.

There is a price, and that is that FPC pushes the type of the parameter, instead of just the value. I'll stick my fingers in my ears until I hear someone complaining that his code is too slow because of that :P

> > Actually I agree with you here. > > Finally :) What does it take to make it non object oriented thingy, > that is, it can be used on $MODE FPC ?

See thread "Suggestion for change". Propose it, defend that it is necessary. If you can defend it, I'll enable it.

??? Why would that be necessary? You need it in C, but in FPC/Delphi, the type is in the varrec.

Hola, do not confuse variants with variant records. A variant is this:

var a:variant;

... and is such a memory weasting thing, but a variant record is this:

type t=record
       case boolean of
         false:(p:longint);
         true:(p:pointer)';
     end;

... which doesn't waste a single byte.

Daniël

Not every changement is a improvement. There is not merit in supporting more ambiguous syntax here. Retrain the few C bigots that keep whining about it.

What? The varargs thing is not something to learn, since unsafe and ambigious (no trailing arguments possible)

and we can learn from Java.

What?

BTW STL as far as I know (I don't know a lot of things regarding STL) try (and maybe did) solve this problems.

STL is afaik very tied to a static (or dynamic with GC at a severe performance penalty) object model. From what I've seen from it the concepts don't work for FPC/Delphi objects.

Again falls in the category "typing only". If you add syntax for each and every shortcut that "could help you sometimes" (translate: save a few keystrokes), you end up with something even worse than Perl.

> However for that see the FAQ about new features, and specially the part > about inventing syntax to save a few keystrokes.

I would like to emphasize this once more. It was written after countless discussions like this, and with a reason:

http://www.freepascal.org/faq.html#extensionselect

All four points (the three explicitely named, and the requirement that future extensions should be more than a oneliner idea, but a complete reviewable proposal for a solution) apply to this discussion. (or in the 4th case, in the next step after the initial discussion, if you still persist)

More than any language afaik. I saw numbers once like 70% of paid programmers are said to work in VB/.NET, though maybe eroded a bit lately by moving to C#.

But the response is not correct. For example, I do not like the fact in VB that I must use "," without parameter if I "don't' want to use" this parameters.

But probably there will be a reason. Some form of disambiguation that this comma provides.

Why is it so important for you that it will not be implemented ? I still do not understand your point of view... sorry :(

Well, first, I still don't know what you want, except that you want to get optionally rid of [] in array of const statements with no leading or trailing normal parameters to save two characters of typing and because it is more C like, neither of which is IMHO worth the trouble.

The broader reason is that I'd like to keep a clean language. Extensions like this are useless ballast. The more extensions you have, the bigger chance in conflicting (as can be seen very clearly in the string types automatic conversions in combinations with stuff like overloading, default params etc)

You don't know if there are any parameters.

I think I'll print that sentence out, frame it, and hang it on the wall :-)

If you have such a case, it is a bad architecture of the software.

The latter one is doubtfull indeed, but very old, and I'm not happy with them, except maybe the ++/-- variants. These I use sometimes though, since it avoids translation errors when C code uses the ++/-- in a loop without rearranging and retesting them.

The FPC macro support is not C compatible, and just like operator overloading makes something possible, that can't be done otherwise.

This is not the case here, since there is array of const.

Then develop your interface without regarding people that just whine because it isn't C.

There is a difference between a need for something to make better and easier work, between "look ma, I can access the system by spinning all over the place".

Well, the latter is varargs. No checking done.

Yeah, but rocks can't, which was the point.

If you want to teach people how to create houses with other materials, you need to show them first that you can create it with rocks, and show them something better after that imho...

No you don't. You take what is the best for the house, and demonstrate that. And that is array of const.

I don't care about that.

I also see the need to make it even better, by making it more flexible that I can do things depends on my needs, instead of the place i am at.

Then write a proposal.

Give us the financing Java has, and we'll show you what you can do in Pascal:-)

Generics are in place. They are also potentially confusing etc etc, but at least they make stuff possible that isn't possible otherwise, which is worth the shot. It is not just about typing and catering to the C crowd.

Define more flexible. I don't care about the modes if it is possible. (some parts of tvarrec might be objpas specific)

I'm perfectly happy with my current selection of OSes.

Obvious: the optional parameters. Many parameters are optional, so VB must be told 'ignore the 3rd and 4th of the 5 optional params' :-)

Michael.

You are welcome to correct me, but I can pass an array as parameter to C, but as a pointer ...

I find it helpful, for example:

function getRange (const S : string; Start, End : integer; i : integer
= 0) : integer;
function getRange (const S : string; Start, End : integer; f :
extended = 0.0) : extended;
function getRange (const S : string; Start, End : integer; s :
string='') : string;
...

Unless there is a magic to overload by return value, this way I can solve the problem of overloading, so it is useful, and I can find places I can use it. Other way to do the same will be to create different name for each function. Well it is possible, but what is easier to remember getRange or getRangeI getRangeF getRangeS etc. ? It also less writing here for the use of the functions, and this less writing make it easier to use the function removing the need to remember "what do I actually need a float or an integer ?", when sometimes the answer is not that simple ... But it also have a down side, and that's to debug it and see what is the correct function that in use. So there are no pros without cons .

Cool, sounds good reason for me :) I'll take this one back.

The only thread I can find about the subject is "Suggestion for change: Overly strict check" should I open a "bug" report of request a feature for that ?

Thanks for clearing it out for me :) I know this as a union (well actually now that I think on that, I forgot about it, when I stopped working with Delphi 4 years ago, and I had only variant as a type in my head).

Daniël

Ambiguous syntax ?! how parameters placed like in normal syntax, can be ambiguous ?

"Fish for an hungry person and he will eat for a day, teach a person to fish, and he could eat every day"

Why do you need literal translation of things ? Why not make them fit to the Pascal way, but learn from the good thing they have ?

The link you gave points to fpc.cfg :P but I did read the right section.

Well
A. I find that the use of [] makes a lot of people to make mistakes because the concept is alian to them, and for some strange reason not using it, make them use the feature better.

B. I do think that not using [] should be optimal by compiler directive rather then something that just exists, but I do see a need for it.

C. The need for not using [] are:
1. For forcing positions for this parameter (many people find it more readable to use a list at the end, rather then on any parameter position).
2. The possible use of array as a list of values inside the parameter rather then as one parameter.
3. Compatibility with other languages. It will make easier porting from one language to another, including translating things with less possible bug due to syntax.
4. Focusing on the task, rather then on the syntax symbols. When you are working fast to solve bugs under a lot of pressure, you find yourself try to fix opening and closing of [], and you find yourself place new parameters outside them, just because of speed, the fact that you are tied etc...
5. Understanding that compiler magic, sometimes needed also for non compiler creation. the TParameters that is used under Writeln, should not be a compiler magic imho.

Pros for using array of const in FPC mode:
A. instead of using overload of any possible type for specific array of integer, array of string etc... You could add in a non object oriented mode a list of multiple types in one parameter. B. The ability to write lower level applications with tools that exists only in higher level.
C. Easier software design, that will require less hacking to solve problems of multiple parameter list.

Cons:
A. Not compatible with Wirth Pascal.
B. Making additional overwork for the FPC team.
C. Make Pascal developer write less overloaded functions. D. Make it closer to Java/C syntax.
E. Divide the FPC developers/users to groups of Pro and Cons.

And still I do not find anything good that VB have to offer us ... It's a language that should have never evolved.. it's a freak of the programming language nature... Every Hugh task at the end pointed to C or C++ solution when you just call a library at the end.

C# is Java by Microsoft. Pure and Simple... I still do not see what good it gives either, alto If we have Microsoft on our side, FPC had a lot more developers and users .

VB love parameters, even if you could have simply solve it by using OOP approach, or using records... That's the only reason.

Sure you can... va_start return to you how many parameters exists on a va_list ...

Cool, send me a picture :D

If you have such a case, it is a bad architecture of the software.

Really ?

Here is something I really had in real life programming.

I created a customer/potential customer feedback form. This form depends on what you needed had more then 40 fields all together (that is all the fields possible depends on the situation of who is the person and what does s/he needs to fill).

Now I had one function that fills few texts (depends on the parameter situation) and return the string that was filled with %s %d etc formats. Now one field can be used more then once. And almost every line have at least one format string. So you need to pass the format function a lot of parameters, in order to complete the form.

For example:

%d/%d/%d (dd/mm/yyyy)

Hello %s(Mr). %s (Van Der Voot),

Thank you for interesting in our %s(product).
%s (Marco) we are more then happy to help you and give you additional information about %s (product).

You can either call us at the phone number of 1234567890 extension %d (10000) for customer support.

You can also contact our sails department at phone number 1234567890 extension %d (666) for upgrading your %s (product), or just to ask additional questions.

You can also contact our support team at the email of (support/product name).

Regards,

Abraham Lincolen,
Late US president.

Count how many format string I do have, and you'll see that I do need few parameters. And it also depends on the email component, because I might even add the email headers inside, and that will also require more parameters.

And this letter is one of few that was sent just for specific operation. Another email/message was sent to the sales department and few other locations depends on the data ...

So in the way you see it, I would have needed a specific format function for each type of text, and that also requires you additional code maintenance that otherwise would not have needed (adding additional line with parameters). It will be more work then just finding the right location for the new parameters.

I can give you more examples if you really need them.

I don't use ++ -- unless that's the writing convention on the language I use. In pascal I use inc and dec ... I find ++ and -- really annoying thing, due to the --i i-- thing, that I always do not remember what first implement and then return value and what is first return a value and then implement...

I also do not like GoTo and we still have it on FPC, also there is a switch to turn it on/off (like what I think should be for my offer).

The FPC macro support is not C compatible, and just like operator overloading makes something possible, that can't be done otherwise.

I still did not find a real use for macros in FPC, but you are more then welcome to open my eyes .

This is not the case here, since there is array of const.

But only for specific modes that require you object oriented support.

I never develop things to "show people" .. I develop things to make them work. And this one will make my and even your work much easier in few ways...

Rock can't build a house or rocks can not be a house ?

Please work with "regular" people. You first need to speak their language (in this case build a house from rocks), before you can try to communicate with them.

I do ! so why not help me to make my life easier when I'm using FPC ?

Sure, as soon as my tree start give me money instead of leafs.

Generics are in place. They are also potentially confusing etc etc, but at least they make stuff possible that isn't possible otherwise, which is worth the shot. It is not just about typing and catering to the C crowd.

Many things that C++ developers showed me that templates (generics) makes their life easier, I showed them how I don't need it in Pascal, and still have the result... you sometimes need to see that there is no spoon and it is your mind that is spinning ;)

It is not possible. If it was possible, it would have worked on all "native" modes (except TP).

That's why it feels more like a hack imho ...
"If you have dark clouds, I can say that there is a good chance you'll have rain, and if it's cold enough might even snow". But it does not mean that there will be rain or snow... it means that it might be ... might is a bad thing for developers... because it might work... it should work, but it does not work.

But I'm not for few reasons:
1. No Pascal OS .
2. I need to choose between *nix or between radmond (that getting closer and closer to *nix), and they are both not what I'm looking for (Mac tiger is a *nix).
3. Almost all existed OS are some type of monolithic kernel... So I can't just change the way that the kernel handle memory, or how it will support file system. I can only make it additional modules that in the best case, will override existed way.
4. Too much patching (of features) make your OS act bad.
5. It's hard to make an OS that will be suited for 100% of your needs, you need to compromise ...
6. I always see room to improve things to make them better, and then some Marco comes and tells me that he is more happy with the existing features and fight me :P

Ido

{$mode objfpc}
procedure bla;
begin
  writeln('bla');
end;
procedure bla(v:array of const);
begin
  writeln('bla[]');
end;
begin
 bla;
 bla([]);
end.

Ah, silly sayings time!

"Give fish to a veganist and you will have wasted a few minutes. Teach him to fish, and you will have wasted days".

Why do you need literal translation of things ?

Because I actually did think about these things. I ported Decal, and saw to what lengths you have to go to keep the STL principles running under Object Pascal

And that's becasue a static objectmodel (or something that can emulate it like dynamic model that is autmatically memory managed) is pretty much a requirement for the STL as it is. (Decal emulated it with interfaces that are refcounted to workaround this. The performance is worse than something like Java or .NET)

Why not make them fit to the Pascal way, but learn from the good thing they have ?

Hollow phrase. If you think I didn't get some lesson from the STL, why don't you simply say what I didn't get?

It is all so vague? We should learn from this, and the greatness of that, but all you've shown so far is one pretty ugly shorthand([]), and the extension of array of const to fpc mode. (which I do not object if possible)

If people don't want to learn a language, they will just fall into the next trap. And teaching a systematic, orthogonal language is much easier.

(snip lots of arguments which are all just trying to make a case for "do like C", IMHO without any merit.

In the 5 years array of const support, I _never_ saw such a problem mentioned, or any problem or misconception about it that wasn't solved by providing the link to the manual part that describes it.

I don't see the need for any syntax changes and extra directives.

Hmm, on second thought, a few pooints I do want to respond to though,

3. Compatibility with other languages. It will make easier porting from one language to another, including translating things with less possible bug due to syntax.

The compability is _so_ superficial that it only will confuse people more. It is different and that isn't solved by trying to make the most superficial syntax.

E.g. C I can do all kinds of dirty tricks, like pass a pointer to where the runtime expects a long, and it will print the address. With Array of Const that generally won't work.

Having them look in the manual for the directive won't solve this either. And the bugs introduced by this careless switching off can be way harder to trace. See above example.

5. Understanding that compiler magic, sometimes needed also for non compiler creation. the TParameters that is used under Writeln, should not be a compiler magic imho.

TParameters?

Pros:
A. A solid, safe, unambiguous and logical language feature

Cons:
A. None.
B. It is not standard Pascal, but hey, neither is probably 90% of FPCs other language features.

Perceived Cons:
A. It is not 1:1 mappable to C. Or Java. The fact that these don't map 1:1 to eachother doesn't matter.
B. Another 50% of FPC features is not mappable to C. Maybe we should get rid of sets too.

(advocate of the devil mode on)
But maybe they will port code too, and fall into loops. Maybe we can better cater to them, since they are the larger group.

I don't see much use in adding more C constructs too. Half of the ones we have are only for C interfacing, or interfacing to C api's (e.g. array of const varargs style). Not for being 1:1 mappable to C.

It's a language that should have never evolved.. it's a freak of the programming language nature... Every Hugh task at the end pointed to C or C++ solution when you just call a library at the end.

I don't am that fond about C and C++ either. IMHO C++ never had a chance because of backwards compability to C (and even Java and C# suffer from this). And half of C's designs is just a result of the original implementors designing the language to avoid as much state in the compiler as possible (external preprocessor to define a constant!??!), so they could compile large kernels (think 20 kwords) with the limited memory they had on the PDP-7.

I don't buy that. The bulk of the developers will go with Microsoft, and Microsoft only. They select Microsoft, they don't select .NET.

Delphi.NET has less users than Delphi had. Why? Borland can't keep up with MS, and users don't want to be a minority (for components, access to new OS api's etc) a second time, and move directly to the MS prefered solution.

The only way to deal with Microsoft in the commercial world is to entirely avoid it, or to entirely embrace it. And with embrace I don't mean to port to .NET, but to change to MICROSOFTS .NET toolchain, and Microsofts toolchain alone (forget about stopgaps as Mono, Delphi.NET etc).

I learned that the hard way, using Borland C++. 99% of the components, source etc had to be ported, begged for special versions with the vendor etc etc, just to work with BCB, since it was all designed for MSVC++ and MSVC++ only, despite being "portable" C++. It will be the same with .NET in practice, despite what a few dreamers think. Simply because the people that go for .NET are all of the kind that want to be closer to Microsoft, not more apart from it.

Delphi was one of the few exceptions for a while on win32. Commercial in competition with MS, it could keep double digit market share for a while as only one, but either Borland neglected a bit too much, or Microsoft became to strong. It doesn't matter (but I think it was a combination of both) ,and it is pretty much over, except for those that either stik to MS, or don't buy the .NET saga.

Seeing that MS didn't even manage convert 0.1% of windows to .NET makes the "in n years, everything will be .NET" somewhat unrealistic IMHO :-)

Oh, and nobody, really NOBODY that ever proposed a feature to FPC managed to avoid "and I think this will get FPC a lot of extra users" standard line. IOW, EVERYBODY dangled that sausage in front of us.

And that includes me, both before and even after I became core. And the others made me see the trouble of some of my proposals.

And keep in mind, while I wrote the .NET faq, and I also wrote the faq about extensions. But I showed them to the other developers before it went live, and they pretty much all agreed.

(actually the sentence that starts with "if sb does the bulk of the work" is one of the compromises out of those discussions. But I agreed with that modification too)

See Michael's mail.

No it doesn't. va_start says how many parametes are in the argument string. If you pass less parameters, it will horribly crash.

Maybe it is something for the anti-patterns club :-)

(snip)
And when you insert, you have to count carefully in both the calling function and the result function.

A sane way would be to make a list of data that uses name,value pairs to substitute each name with its corresponding value.

And you can then pass this happily around, append parts, and you decoupled the horrible order dependancy that is not necessary, and created maintainable code.

(I just wanted to be fair, and not slam that functionality while I actually used it with FPC, though a handful times in 10 years)

I also do not like GoTo and we still have it on FPC, also there is a switch to turn it on/off (like what I think should be for my offer).

Ah, but we already had goto, and then made the switch. You propose to ADD a goto.

The main place it is used for is for calling convention modifiers. A use that is also pretty common in C libraries.

(from my mind)

{$ifdef win32}
{$define mycalling=stdcall}
{$else}
{$define mycalling=cdecl}
{$endif}
procedure xx; mycalling; external 'libraryname' name 'externalname';

> This is not the case here, since there is array of const. But only for specific modes that require you object oriented support.

I've already said I'm not against that. But maybe that will be difficult, and causes the loss of the smaller footprint that the non Object Pascal modes have.

I never develop things to "show people" .. I develop things to make them work. And this one will make my and even your work much easier in few ways...

Not mine. As I said, I never encountered any wish about this before. In say the 7 years of object pascal functionality.

There have been some issues with array of const in the past, but they were all about C interop (being able to call C varargs). Not C source level compability.

Rocks can't build a house.

I work with regular people. I have been doing FPC support for quite some time, answering messages, closing bugreports etc etc. And therefore I know first hand that any new syntax causes a certain amount of problems (rise in support pertaining to that issue). Specially if you have multiple variants and nuances of the feature.

That is not always unavoidable (e.g. we do support array of const cdecl/varargs), but it must be really worth it (e.g. being able to complete the interface to compiled C functions, varargs was the last major thing we couldn't do), and not superficial typing.

Keep in mind that you only see people having some initial problem with FPC, and then they move on, and come into the FPC support channels. (forum, maillists, personal mail, bug tracker), and contact us directly.

I meant "I'm not against that". Though I maybe see practical problems. But I maybe there is an obvious workaround for that. I'll leave that to the compiler devels.

Show me a generic typesafe container. Fully typesafe. Even Decal doesn't.

FPC is not fully static. Things we kept strictly separate in 1.0 might be more lax in 2.0. So while there is a fair chance that it indeed is not possible, it is not 100% certainly so. E.g. in 1.0 times we cared way more about the size of a minimal problem using the default RTL than nowadays.

That's why it feels more like a hack imho ...

No. I was there. The decision to keep them apart were IIRC twofold:
- avoid identifier space polution by the new delphi units which might be a problem for TP code. (so identifiers added in the Delphi system could cause trouble for existing TP programs that already defined that identifier)
- footprint.

Use classic Mac OS versions (:-))

2. I need to choose between *nix or between radmond (that getting closer and closer to *nix), and they are both not what I'm looking for (Mac tiger is a *nix).

OS X is a mach kernel (even though it has a very vast Unix userland). So is Windows NT (at least the original design), BeOS, Minix (direct precursor to Linux in some ways).

You could say the unix part of OS X is a module.

3. Almost all existed OS are some type of monolithic kernel... So I can't just change the way that the kernel handle memory, or how it will support file system. I can only make it additional modules that in the best case, will override existed way.

See Mach OS.

4. Too much patching (of features) make your OS act bad.

Not just OSes. Also languages :)

5. It's hard to make an OS that will be suited for 100% of your needs, you need to compromise ...

I agree. More generally for all software. However OSes is particularly hard due to the driver problem. All minor OSes (and even some major) are struggling to get enough hardware support.

The first question I ask a new OS developer is that.

6. I always see room to improve things to make them better, and then some Marco comes and tells me that he is more happy with the existing features and fight me :P

That's because Marco sees, and has seen some of the problems that not carefully crafted extensions can cause. Specially extensions that are very emotionally driven.

It is not that I'm holy or always right. On the contrary; it's because I also made these mistakes. (and probably even worse ones, and still do once in a while). Usually the compiler devels (typically Peter/Florian/Jonas) made me see I made idiotic suggestions.

This process pretty much was the reason for the FAQ entry about compiler extensions. After its inception, a few people have managed to make a real point using example implementations and a lot of reviewing, and got them accepted.

If this is really the case that cause you demand var_args feature, then obviously you have problem with your software design. I agree with Marco. :) I wrote a program to solve a problem exactly like this without need of var_args feature. Even though var_args is provided, I won't use it either, since -IMO- var_args isn't the correct way to solve this kind of problem.

The above problem can be solved easily with a simple "find-and-replace"-like algorithm. IMO, basically this is a template filling. Just put a unique tags on every place that need to be filled with a value. Parse the template and replace every tag with appropriate value and format. Likely this must be done by a specialized class for this purpose.

With this solution, my program can do the job very well with more than 200 kind of tags on more than 20 kind of templates (and increasing by the day). The users can even build their own template(s) through a template builder wizard from my application. I believe the wizard can't be easily build just using var_args. Your sample above, using my solution will become a template like this (less or more):

Or am I missing something here?

-Bee-

has Bee.ography at:
http://beeography.wordpress.com

You are missing something :)

First of all it is sad that format is not useful for such a thing, but my example about using a lot of parameters for a function, and you will need to keep on either rewrite a function, or overload a function with new parameters, when you do not have array of const/var args ... It was giving for "show me one use ..." so I gave one :)

BTW I would have either solve this problem for real, either by using tags like you have used, and the use of replaceall function, or if the letter was a inside my source, I would have do it

'Hello ' + Fields.Name + ...

Depends on the situation I could design it.

However a reason that you must agree that it's easier to use array of const rather then working harder is to use SQL parameters.

Because if you will not use array of char, you will doomed to do it in a very very very hard way, and not that easy as well imho:

with array of const:

params([a,b,c,d,e,f,g,h,a,a,a,z]); //Some DB can allow you to create temporary variable, so it can save you to call the same paramter more then once ...

Without array of const:

sql.getparam(1).value := a;
sql.getparam(2).value := b;
sql.getparam(3).value := c;
...
sql.getparam(7000000).value := z;

There is a Delphi component for BDE (if I remember correctly) that works like the second one ... on both cases you need to count parameters, and place it on the right order... and a "for" loop will not help with the parameters values, unless it saved at the same order as the getparam order ... and then you made a double work ...

Ido
ik.homelinux.org/index.rhtml/home ;) (still under havy work btw)

P.S. Now I actually need to answer Marco, although I thought to stop this threading :(