Operators << and >> are for shifting, overloading opCall("like")("this") is ugly to me :P and hard to type. So I have yet another idea for type-safe variable arguments. Here's the idea in code:


class Foo
{
   char[] buf;
   void opStream(char[] x) { buf ~= x; }
   void opStream(char x) { buf ~= x; }
   void opStream(Object o) { buf ~= o.toString(); }
   char[] toString() { return buf; }
}


int main()
{
   Foo foo;
   foo$("this calls", " opStream for", " each parameter", '\n');
   printf("Foo = '%.*s'\n", foo.toString());
   return 0;
}


I just threw in the symbol $ so it doesn't conflict with opCall and so you can better understand what it's doing. opStream always has void return type and exactly one parameter. For input streams you could use out parameters.


-- 
Christopher E. Miller

Vathix <vathix@dprogramming.com> wrote in news:c5rhae$1eek$1 @digitaldaemon.com:

> Operators << and >> are for shifting, overloading opCall("like")("this") is ugly to me :P and hard to type. So I have yet another idea for type-safe variable arguments.

This is like the proposal I had for opWrite and opRead a while back. In general I like the idea.

http://www.digitalmars.com/drn-bin/wwwnews?D/19072

On Sat, 17 Apr 2004 11:09:04 -0400, Vathix wrote:

> Operators << and >> are for shifting, overloading opCall("like")("this")
> is ugly to me :P and hard to type. So I have yet another idea for
> type-safe variable arguments. Here's the idea in code:
> 
> 
> class Foo
> {
>     char[] buf;
>     void opStream(char[] x) { buf ~= x; } void opStream(char x) { buf ~=
>     x; }
>     void opStream(Object o) { buf ~= o.toString(); } char[] toString() {
>     return buf; }
> }
> }
> 
> int main()
> {
>     Foo foo;
>     foo$("this calls", " opStream for", " each parameter", '\n');
>     printf("Foo = '%.*s'\n", foo.toString()); return 0;
> }
> }
> 
> I just threw in the symbol $ so it doesn't conflict with opCall and so you can better understand what it's doing. opStream always has void return type and exactly one parameter. For input streams you could use out parameters.


I must admit that something along the lines of your opStream example does look desirable.

i like this idea, it reminds me of the Amos language :)
u have my vote ;)

Vathix wrote:

> So I have yet another idea for type-safe variable arguments.
[...]

This is not "another idea". You just specialized for streams my general proposal: pre- or postprocessing not possible; only one state in the declaration stage, therefore the next state implicitely denoted by void type; opCall renamed to opStream; at the call stage `,' instead of `;'.

Would you please explain, why it would be good, to have another syntax extension for every special case that may arise?

So long!

Manfred Nowak wrote:
> Vathix wrote:
> 
> 
>>So I have yet another idea for type-safe variable arguments.
> 
> [...]
> 
> This is not "another idea". You just specialized for streams my general
> proposal: pre- or postprocessing not possible; only one state in the
> declaration stage, therefore the next state implicitely denoted by void
> type; opCall renamed to opStream; at the call stage `,' instead of `;'.
> 
> Would you please explain, why it would be good, to have another syntax
> extension for every special case that may arise?
> 
> So long! 

I have proposed many ideas here for type safe variable arguments; this is another one. I called it opStream because most (all?) cases where you want variable arguments is to stream data into an object. I am proposing a friendlier syntax, because foo("this is")(" using opCall")(" and doesn't")(" look")(" too pretty"), and the C++ method of using << and >> is out of the question. I don't stand by my proposals 100%, I just say what is interesting to me and hope it is inspiring to improve anything.


-- 
Christopher E. Miller

Vathix wrote:
> Operators << and >> are for shifting, overloading opCall("like")("this") is ugly to me :P and hard to type. So I have yet another idea for type-safe variable arguments. Here's the idea in code:
> 
> 
> class Foo
> {
>    char[] buf;
>    void opStream(char[] x) { buf ~= x; }
>    void opStream(char x) { buf ~= x; }
>    void opStream(Object o) { buf ~= o.toString(); }
>    char[] toString() { return buf; }
> }
> 
> 
> int main()
> {
>    Foo foo;
>    foo$("this calls", " opStream for", " each parameter", '\n');
>    printf("Foo = '%.*s'\n", foo.toString());
>    return 0;
> }

Instead of calling these ideas "type safe variable arguments" I think it should be called something like "syntactic sugar for multiple function calls". Manfred's idea of using ";" was similar and it took me forever to realize he wasn't talking about arguments to one function call - he was talking about making multiple function calls. This is quite different from variable arguments using a single function call and I'd expect C/C++ users to see something that looks like a regular function call and expect it to behave like a regular function call. The concept of "varargs" or "variable arguments" has always been applied to a single function call so we should keep it that way.

These ideas have been bouncing around at least since Walter's original opCall input/output idea:
 http://www.digitalmars.com/drn-bin/wwwnews?D/18945
I'm sure you're aware of the history since you mention opCall but not everyone might know what motivates these proposals.

-Ben

ps - the posting I made a while back
  http://www.digitalmars.com/drn-bin/wwwnews?D/26932
was what I thought Manfred was talking about with "type-safe variable arguments" since it allows vararg style calls with type checking.

Ben Hinkle wrote:

> Vathix wrote:
> 
>> Operators << and >> are for shifting, overloading opCall("like")("this") is ugly to me :P and hard to type. So I have yet another idea for type-safe variable arguments. Here's the idea in code:
>>
>>
>> class Foo
>> {
>>    char[] buf;
>>    void opStream(char[] x) { buf ~= x; }
>>    void opStream(char x) { buf ~= x; }
>>    void opStream(Object o) { buf ~= o.toString(); }
>>    char[] toString() { return buf; }
>> }
>>
>>
>> int main()
>> {
>>    Foo foo;
>>    foo$("this calls", " opStream for", " each parameter", '\n');
>>    printf("Foo = '%.*s'\n", foo.toString());
>>    return 0;
>> }
> 
> 
> Instead of calling these ideas "type safe variable arguments" I think it should be called something like "syntactic sugar for multiple function calls". Manfred's idea of using ";" was similar and it took me forever to realize he wasn't talking about arguments to one function call - he was talking about making multiple function calls. This is quite different from variable arguments using a single function call and I'd expect C/C++ users to see something that looks like a regular function call and expect it to behave like a regular function call. The concept of "varargs" or "variable arguments" has always been applied to a single function call so we should keep it that way.

All right, good point.
So
   foo("hello"; " world");
would be at least
   foo("hello");
   foo(" world");
I like it..
Sorry about my post.


-- 
Christopher E. Miller

Vathix wrote:

[...]
> I am proposing a friendlier syntax, because foo("this is")(" using
> opCall") (" and doesn't")(" look")(" too pretty")
[...]

Agreed. However:
 foo("this is"; " using opCall"; " and doesn't"; "look"; " too pretty")
is not lookimg that bad.

So long!

Ben Hinkle wrote:

[...]
> This is quite  different from variable arguments using a single function call
[...]

I do not see the difference you are proposing here. If the details of the declaration of such a, lets call it "variadic object", are hidden it would become indistinguishable from a function.

I do not see a need to keep up the feeling of "variadic objects" must be functions. I already gave a _working_ example of a generic "variadic object" of a list that is able to adapt to every codable type. None of the proposals I have seen so far has even proposed to be able to do that.

Furthermore: by changing the states of a "variadic object" from structs to classes it seems possible to "derive" "variadic objects" from given ones, thereby expanding the language that is accepted by such a "derived variadic object". How does this fit into the feeling of a function?

By hiding the details of a declaration I mean something like:

  variadic( ( T1, T2)*:R ){
    R result;
    // declarations
    // preprocess
    switch{ // only one state needed in this special case
      case T1 p1:
        // declarations
        // do something with p1 and result
      case T2 p2:
        // declarations
        // do something else with p2 and result
    }
    // postprocess
    return R;
  }

At the call side:

  T1 ap1, ap3;
  T2 ap2;
  R res;
  // prepare the call
  res= variadic( ap1, ap2, ap3);

Now please explain why you still consider this as multiple function calls.


> These ideas have been bouncing around at least since Walter's original
> opCall input/output idea:
>   http://www.digitalmars.com/drn-bin/wwwnews?D/18945
> I'm sure you're aware of the history since you mention opCall but not
> everyone might know what motivates these proposals.

Thanks! That was some weeks before I started digging into D. I therefore did not notice, that Walter has already laid out the playgrounds of such _packaged_ opCalls and I am somehow reinventing a wheel.

Please note, that in the example given above it is very well possible to nest the calls of the "variadic object" provided, that the return types are assigned properly:

  res= variadic( ap1, variadic( ap2, ap3), ap4);


> ps - the posting I made a while back
>    http://www.digitalmars.com/drn-bin/wwwnews?D/26932
> was what I thought Manfred was talking about with "type-safe variable
> arguments" since it allows vararg style calls with type checking.

Commented on it.

So long!