A cool way to do 'variable argument lists' would be to allow for methods with a single parameter that are overloaded for various types to be expressed with one call, using commas to separate the arguments.  For example:

instead of
print("The quick brown fox");
print(10);
print(20.5);

one could write
print("The quick brown fox", 10, 20.5);

and then the compiler would translate it to the above. That would be type-safe, although a little slower than the C method (because of multiple calls), but it would improve those tedious 'print' blocks of code, as well as being easier on the eye.

That is an intriguing solution!

"Achilleas Margaritis" <axilmar@in.gr> wrote in message news:bivp1f$1qvj$1@digitaldaemon.com...
> A cool way to do 'variable argument lists' would be to allow for methods with a single parameter that are overloaded for various types to be expressed with one call, using commas to separate the arguments.  For example:
>
> instead of
> print("The quick brown fox");
> print(10);
> print(20.5);
>
> one could write
> print("The quick brown fox", 10, 20.5);
>
> and then the compiler would translate it to the above. That would be type-safe, although a little slower than the C method (because of multiple calls), but it would improve those tedious 'print' blocks of code, as well as being easier on the eye.
>
>

But wouldn't it mislead the coder as to the serialisation stipulations in multi-threaded systems?

"Walter" <walter@digitalmars.com> wrote in message news:bj0sfg$9r0$1@digitaldaemon.com...
> That is an intriguing solution!
>
> "Achilleas Margaritis" <axilmar@in.gr> wrote in message news:bivp1f$1qvj$1@digitaldaemon.com...
> > A cool way to do 'variable argument lists' would be to allow for methods with a single parameter that are overloaded for various types to be expressed with one call, using commas to separate the arguments.  For example:
> >
> > instead of
> > print("The quick brown fox");
> > print(10);
> > print(20.5);
> >
> > one could write
> > print("The quick brown fox", 10, 20.5);
> >
> > and then the compiler would translate it to the above. That would be type-safe, although a little slower than the C method (because of
multiple
> > calls), but it would improve those tedious 'print' blocks of code, as
well
> > as being easier on the eye.
> >
> >
>
>

You lost me there!

"Matthew Wilson" <matthew@stlsoft.org> wrote in message news:bj16vn$om3$1@digitaldaemon.com...
> But wouldn't it mislead the coder as to the serialisation stipulations in multi-threaded systems?
>
> "Walter" <walter@digitalmars.com> wrote in message news:bj0sfg$9r0$1@digitaldaemon.com...
> > That is an intriguing solution!
> >
> > "Achilleas Margaritis" <axilmar@in.gr> wrote in message news:bivp1f$1qvj$1@digitaldaemon.com...
> > > A cool way to do 'variable argument lists' would be to allow for
methods
> > > with a single parameter that are overloaded for various types to be expressed with one call, using commas to separate the arguments.  For example:
> > >
> > > instead of
> > > print("The quick brown fox");
> > > print(10);
> > > print(20.5);
> > >
> > > one could write
> > > print("The quick brown fox", 10, 20.5);
> > >
> > > and then the compiler would translate it to the above. That would be type-safe, although a little slower than the C method (because of
> multiple
> > > calls), but it would improve those tedious 'print' blocks of code, as
> well
> > > as being easier on the eye.
> > >
> > >
> >
> >
>
>

Walter wrote:
> 
> You lost me there!
> 
> "Matthew Wilson" <matthew@stlsoft.org> wrote in message news:bj16vn$om3$1@digitaldaemon.com...
> > But wouldn't it mislead the coder as to the serialisation stipulations in multi-threaded systems?
> >
> > "Walter" <walter@digitalmars.com> wrote in message news:bj0sfg$9r0$1@digitaldaemon.com...
> > > That is an intriguing solution!
> > >
> > > "Achilleas Margaritis" <axilmar@in.gr> wrote in message news:bivp1f$1qvj$1@digitaldaemon.com...
> > > > A cool way to do 'variable argument lists' would be to allow for
> methods
> > > > with a single parameter that are overloaded for various types to be expressed with one call, using commas to separate the arguments.  For example:
> > > >
> > > > instead of
> > > > print("The quick brown fox");
> > > > print(10);
> > > > print(20.5);
> > > >
> > > > one could write
> > > > print("The quick brown fox", 10, 20.5);
> > > >
> > > > and then the compiler would translate it to the above. That would be type-safe, although a little slower than the C method (because of
> > multiple
> > > > calls), but it would improve those tedious 'print' blocks of code, as
> > well
> > > > as being easier on the eye.

I think his idea is this: Assume that could command to break up a parameter list into more than one call to the same function name. Let's use a the keyword 'serialize' for this. Then

   serialize print(int i) { .... } ;
   serialize print(char [] s) { .... };

could command the compiler to break up an arbitrary parameter list of ints and strings into separate calls:

  print("i=",i,"  j=",j,"\n");

would just be compiled as if the programmer had written:

  print("i=");
  print(i);
  print("  j=");
  print(j);
  print("\n");

I think it's an interesting "low level" idea, that appeals to me (as a basically C, Perl and "low level thinking" man). Although I'm not sure what the consequences are.

I would still prefer a solution for a clean variable length parameter lists
(like in Visual Basic!).

But Achilleas idea might be the next best thing and it should be very easy to implement. Just look after each parameter whether a matching 'serialize' function exists.

On the other hand, it is also unclear, whether the necessary wrapping of a variable
parameter list into a clean object array will have a performance advantage.
If it doesn't, then this suggestion might have a value of its own.

-- 
Helmut Leitner    leitner@hls.via.at
Graz, Austria   www.hls-software.com

"Helmut Leitner" <leitner@hls.via.at> wrote in message news:3F54530C.B0855051@hls.via.at...
>
>
> Walter wrote:
> >
> > You lost me there!
> >
> > "Matthew Wilson" <matthew@stlsoft.org> wrote in message news:bj16vn$om3$1@digitaldaemon.com...
> > > But wouldn't it mislead the coder as to the serialisation stipulations
in
> > > multi-threaded systems?
> > >
> > > "Walter" <walter@digitalmars.com> wrote in message news:bj0sfg$9r0$1@digitaldaemon.com...
> > > > That is an intriguing solution!
> > > >
> > > > "Achilleas Margaritis" <axilmar@in.gr> wrote in message news:bivp1f$1qvj$1@digitaldaemon.com...
> > > > > A cool way to do 'variable argument lists' would be to allow for
> > methods
> > > > > with a single parameter that are overloaded for various types to
be
> > > > > expressed with one call, using commas to separate the arguments.
For
> > > > > example:
> > > > >
> > > > > instead of
> > > > > print("The quick brown fox");
> > > > > print(10);
> > > > > print(20.5);
> > > > >
> > > > > one could write
> > > > > print("The quick brown fox", 10, 20.5);
> > > > >
> > > > > and then the compiler would translate it to the above. That would
be
> > > > > type-safe, although a little slower than the C method (because of
> > > multiple
> > > > > calls), but it would improve those tedious 'print' blocks of code,
as
> > > well
> > > > > as being easier on the eye.
>
> I think his idea is this: Assume that could command to break up a
parameter
> list into more than one call to the same function name. Let's use a the keyword 'serialize' for this. Then
>
>    serialize print(int i) { .... } ;
>    serialize print(char [] s) { .... };
>
> could command the compiler to break up an arbitrary parameter list of ints and strings into separate calls:
>
>   print("i=",i,"  j=",j,"\n");
>
> would just be compiled as if the programmer had written:
>
>   print("i=");
>   print(i);
>   print("  j=");
>   print(j);
>   print("\n");
>
> I think it's an interesting "low level" idea, that appeals to me (as a
basically C,
> Perl and "low level thinking" man). Although I'm not sure what the
consequences are.
>
> I would still prefer a solution for a clean variable length parameter
lists
> (like in Visual Basic!).
>
> But Achilleas idea might be the next best thing and it should be very easy
to implement.
> Just look after each parameter whether a matching 'serialize' function
exists.
>
> On the other hand, it is also unclear, whether the necessary wrapping of a
variable
> parameter list into a clean object array will have a performance
advantage.
> If it doesn't, then this suggestion might have a value of its own.

It seems at first blush like a pretty good idea. I'm worrying that there's a gotcha I'm not seeing. It does seem to rather neatly solve the typesafe problem.

Walter wrote:
> It seems at first blush like a pretty good idea. I'm worrying that there's a gotcha I'm not seeing. It does seem to rather neatly solve the typesafe problem.

And there would be a number of nice uses e. g.

   serialize drawto(int x,int y);

   moveto(0,0);
   drawto(10,0,10,10,0,10,0,0);

or (in connection with the last example):

   serialize print(Format f,int i);

   print("i=",i,Format("j= %06x\n"),j);

====

Problems might come from needing a 'sticky' parameter type that would have to be repeated on all subsequent calls:

   serialize fprintf(sticky FILE f,char [] s);
   serialize fprintf(sticky FILE f,int i);

because

   fprintf(f,"i=",i);

should transform to

   fprintf(f,"i=");
   fprintf(f,i);

although even this might also be easy to implement: after a serialize call resolution just keep the 'sticky' parameters.

But I share your feelings. It almost looks too good and simple. There must be some hidden traps.

-- 
Helmut Leitner    leitner@hls.via.at
Graz, Austria   www.hls-software.com

Walter wrote:
> "Helmut Leitner" <leitner@hls.via.at> wrote in message
> news:3F54530C.B0855051@hls.via.at...
> 
>>
>>Walter wrote:
>>
>>>You lost me there!
>>>
>>>"Matthew Wilson" <matthew@stlsoft.org> wrote in message
>>>news:bj16vn$om3$1@digitaldaemon.com...
>>>
>>>>But wouldn't it mislead the coder as to the serialisation stipulations
> 
> in
> 
>>>>multi-threaded systems?
>>>>
>>>>"Walter" <walter@digitalmars.com> wrote in message
>>>>news:bj0sfg$9r0$1@digitaldaemon.com...
>>>>
>>>>>That is an intriguing solution!
>>>>>
>>>>>"Achilleas Margaritis" <axilmar@in.gr> wrote in message
>>>>>news:bivp1f$1qvj$1@digitaldaemon.com...
>>>>>
>>>>>>A cool way to do 'variable argument lists' would be to allow for
>>>
>>>methods
>>>
>>>>>>with a single parameter that are overloaded for various types to
> 
> be
> 
>>>>>>expressed with one call, using commas to separate the arguments.
> 
> For
> 
>>>>>>example:
>>>>>>
>>>>>>instead of
>>>>>>print("The quick brown fox");
>>>>>>print(10);
>>>>>>print(20.5);
>>>>>>
>>>>>>one could write
>>>>>>print("The quick brown fox", 10, 20.5);
>>>>>>
>>>>>>and then the compiler would translate it to the above. That would
> 
> be
> 
>>>>>>type-safe, although a little slower than the C method (because of
>>>>
>>>>multiple
>>>>
>>>>>>calls), but it would improve those tedious 'print' blocks of code,
> 
> as
> 
>>>>well
>>>>
>>>>>>as being easier on the eye.
>>
>>I think his idea is this: Assume that could command to break up a
> 
> parameter
> 
>>list into more than one call to the same function name. Let's use a the
>>keyword 'serialize' for this. Then
>>
>>   serialize print(int i) { .... } ;
>>   serialize print(char [] s) { .... };
>>
>>could command the compiler to break up an arbitrary parameter list of ints
>>and strings into separate calls:
>>
>>  print("i=",i,"  j=",j,"\n");
>>
>>would just be compiled as if the programmer had written:
>>
>>  print("i=");
>>  print(i);
>>  print("  j=");
>>  print(j);
>>  print("\n");
>>
>>I think it's an interesting "low level" idea, that appeals to me (as a
> 
> basically C,
> 
>>Perl and "low level thinking" man). Although I'm not sure what the
> 
> consequences are.
> 
>>I would still prefer a solution for a clean variable length parameter
> 
> lists
> 
>>(like in Visual Basic!).
>>
>>But Achilleas idea might be the next best thing and it should be very easy
> 
> to implement.
> 
>>Just look after each parameter whether a matching 'serialize' function
> 
> exists.
> 
>>On the other hand, it is also unclear, whether the necessary wrapping of a
> 
> variable
> 
>>parameter list into a clean object array will have a performance
> 
> advantage.
> 
>>If it doesn't, then this suggestion might have a value of its own.
> 
> 
> It seems at first blush like a pretty good idea. I'm worrying that there's a
> gotcha I'm not seeing. It does seem to rather neatly solve the typesafe
> problem.

It makes it difficult to implement thread-safe varargs, since you have to save (thread specific) data from previous calls.  In some architectures, getting/setting thread-specific data may require a syscall (to get the process or thread ID), which will impose a serious performance penalty.  I earlier suggested a similar proposal, but one that passes a state variable from call to call.

Although I am playing with more flexible versions, my original idea was to require that the varargs function return the same value as its first parameter.  So printf would be declared with a prototype like this:

varargs char[] printf(char[], ...);

You would then declare various implementation functions, including the one (if desired for the case where there were no additional functions:

char[] printf(char[])
{
  ...
}

char[] printf(char[], int)
{
  ...
}

char[] printf(char[], char[])
{
  ...
}

and so on.  When a varargs call was made, it would be turned into a recursive call of the various implementations.  So the call

printf("%s %d %d %d\n", str,a,b,c);

would be translated into this:

printf(printf(printf(printf("%s %d %d %d\n",str),a),b),c);

This variation requires no thread-specific data, because the return code from each implementation is passed in as the first argument of the next impelementation.  So, in the previous example, the innermost printf() will return "%d %d %d\n", the second returns "%d %d\n", and so on.  The last printf() returns "".

> Problems might come from needing a 'sticky' parameter type that would have to be repeated on all subsequent calls:
>
>    serialize fprintf(sticky FILE f,char [] s);
>    serialize fprintf(sticky FILE f,int i);
>
> because
>
>    fprintf(f,"i=",i);
>
> should transform to
>
>    fprintf(f,"i=");
>    fprintf(f,i);
>
> although even this might also be easy to implement: after a serialize call resolution just keep the 'sticky' parameters.
>
> But I share your feelings. It almost looks too good and simple. There must be some hidden traps.
>

Then the solution would be to uses a class instead of free function (or support both). We could have something like:

auto serialize class fprintf
{
public:
    this(some_args);

    void do_serialize(int i);
    void do_serialize(char [] s);
}

The function name could also be an operator like () or << or have
a better name.

Also exact modifier for classes and or functions might be changed.

We could maybe support a return value but IMO exceptions would typically be used if we must terminate before reading all parameters.... Neverthless, in some case it might be interesting to support a return value to control what to do (continue with next arg, break silently, break with an error, skip next arg,...)

The constructor will get first arguments (sticky parameters) and could store then as member for later uses. We could have more than one constructor provide there are no ambiguities. We could also have a destructor (that might flush the stream for example).

Can somebody please tell me how this idea is better than mine that I posted a couple hours before this one, besides that it's a simpler rule? You guys are making up all these rules to do things and my idea put it all together nicely. With mine you could buffer output, return values, have startup and exit code, decide which variables are "sticky" just by adding a parameter, it would be multithread safe as far as I can tell...

Here:

void printall(this ...)
{
this(char* sz) print(sz); }
this(int i) { print(i); }
}

or

void fprintd(FILE *f, this ...)
{
this(char[] s) { c.stdio.fwrite(s, 1, s.length, f); }
this(int i) { c.stdio.fwrite(&i, i.size, 1, f); }
}


"Achilleas Margaritis" <axilmar@in.gr> wrote in message news:bivp1f$1qvj$1@digitaldaemon.com...
> A cool way to do 'variable argument lists' would be to allow for methods with a single parameter that are overloaded for various types to be expressed with one call, using commas to separate the arguments.  For example:
>
> instead of
> print("The quick brown fox");
> print(10);
> print(20.5);
>
> one could write
> print("The quick brown fox", 10, 20.5);
>
> and then the compiler would translate it to the above. That would be type-safe, although a little slower than the C method (because of multiple calls), but it would improve those tedious 'print' blocks of code, as well as being easier on the eye.
>
>