[fpc-devel] va(r)_arg vs open array

[ik]

On 10/3/06, Marco van de Voort <marcov at stack.nl> wrote:
> > On 10/2/06, Marco van de Voort <marcov at stack.nl> wrote:
>
> > > 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.
> >
> > 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.
>
> 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.

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

>
> > >
> > > 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.
> >
> > But we can learn from C
>
> 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.

"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 ?

>
> > > In theory there could. I don't really see thet use, since the procedure can
> > > detect that no other params are following
> >
> > 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.
>
> 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

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

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

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.

>
> > > What's next, people on Windows to implement the whole of VB syntax, because
> > > that is the dominant languag there?
> >
> > Last time I checked VB is more dominant language then delphi and other
> > languages.
>
> 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#.

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 .

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

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

>
> > 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)
>
> > > 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
> >
> > 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.
>
> You don't know if there are any parameters.

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

>
> > > > 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.
> >
> > It's not a bad situation to have 500 functions with all the possible
> > parameters I might need ?
>
> I think I'll print that sentence out, frame it, and hang it on the wall :-)

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 %s at company.com
(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.

>
> > > That is just kidding. Seriously, don't take the whining to seriously. The
> > > next thing they want will be macro's etc etc.
> >
> > 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 :)
>
> 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.

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.

>
> > > 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 ..
>
> Then develop your interface without regarding people that just whine because
> it isn't C.

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

>
> > 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.
>
> > > 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.
> >
> > But people can build houses from rocks, so they think that only rocks
> > can create houses.
>
> Yeah, but rocks can't, which was the point.

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

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

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.

>
> > > 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?
> >
> > 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 don't care about that.

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

>
> > 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.
>
> > > 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.
> >
> > 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 ...
>
> Give us the financing Java has, and we'll show you what you can do in
> Pascal:-)

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

>
> > > 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.
> >
> > What is not possible in making open array more flexible and make it
> > work in more modes then Delphi and ObjFPC ?
>
> Define more flexible. I don't care about the modes if it is possible. (some
> parts of tvarrec might be objpas specific)

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.

>
> > > 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.
> >
> > 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)
>
> I'm perfectly happy with my current selection of OSes.

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