www.digitalmars.com         C & C++   DMDScript  

D - Variable arguments: opStream

reply Vathix <vathix dprogramming.com> writes:
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
Apr 17 2004
next sibling parent Patrick Down <pat codemoon.com> writes:
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. D/19072
Apr 17 2004
prev sibling next sibling parent John Reimer <jjreimer telus.net> writes:
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.
Apr 17 2004
prev sibling next sibling parent h3r3tic <h3r3tic_member pathlink.com> writes:
i like this idea, it reminds me of the Amos language :)
u have my vote ;)
Apr 17 2004
prev sibling next sibling parent reply Manfred Nowak <svv1999 hotmail.com> writes:
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!
Apr 18 2004
parent reply Vathix <vathix dprogramming.com> writes:
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
Apr 18 2004
next sibling parent Manfred Nowak <svv1999 hotmail.com> writes:
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!
Apr 18 2004
prev sibling parent reply Mike <Mike_member pathlink.com> writes:
Hi!

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.

I'm a C++ programmer interested in switching to D, however I dislike not having cin and cout in D. I understand that the << and >> operators are out of question, but since D eliminated the need for a -> operator couldn't you just use <- and -> for streaming? int i; cin -> i; cout <- "i is " <- i <- endl; That would call cin.opStreamIn and cout.opStreamOut ... bad idea? -Mike
Apr 19 2004
next sibling parent Mike <Mike_member pathlink.com> writes:
After thinking a bit about it I came up with an extended solution. No opStream,
but a new keyword ("streaming" or "multi" or whatever):

class bar
{

/* The "streaming" keyword (or "multi" or whatever) declares a property as
"streamable" */

streaming void foo1(int i) { /* ... */ }
streaming void foo1(char c) { /* ... */}

streaming void foo2(int i) { /* ... */}
streaming void foo2(char c) { /* ... */}

streaming int foo1() { return /* ... */}
streaming char foo1() { return /* ... */}

streaming int foo2() { return /* ... */}
streaming char foo2() { return /* ... */}

/* ... */

}

Later on:

bar b;
int i = 3;
char c = 'a'
b.foo1 <- i <- c; // calls void bar.foo1(i) and void bar.foo1(c)
b.foo2 -> i -> c; // calls int bar.foo2() and char bar.foo2()

Maybe you find that plausible in some way or the other, but I think that
wouldn't be too bad :-)

-Mike
Apr 19 2004
prev sibling parent reply John Reimer <jjreimer telus.net> writes:
 I'm a C++ programmer interested in switching to D, however I dislike not having
 cin and cout in D.
 
 I understand that the << and >> operators are out of question, but since D
 eliminated the need for a -> operator couldn't you just use <- and -> for
 streaming?
 
 int i;
 cin -> i;
 cout <- "i is " <- i <- endl;
 
 That would call cin.opStreamIn and cout.opStreamOut ... bad idea?
 
 -Mike
 
 

<< and >> are not out of the question, just likely not preferred by some programmers (probably the reason this discussion doesn't explore them: they're looking for a better way). The DSC.io project provides these C++-style stream operators as well as a different variation. It's the programmers choice as to which to use in an application. This very nicely implemented library is being discussed at www.dscource.org, and I believe is close to beta access so that others can play with it (I'm really, really hoping ;-) ).
Apr 19 2004
next sibling parent John Reimer <jjreimer telus.net> writes:
 << and >> are not out of the question, just likely not preferred by some 
 programmers (probably the reason this discussion doesn't explore them: 
 they're looking for a better way).  The DSC.io project provides these 
 C++-style stream operators as well as a different variation.  It's the 
 programmers choice as to which to use in an application.  This very 
 nicely implemented library is being discussed at www.dscource.org, and I 
 believe is close to beta access so that others can play with it (I'm 
 really, really hoping ;-) ).

Argh! I meant www.dsource.org, of course.
Apr 19 2004
prev sibling parent reply "Ivan Senji" <ivan.senji public.srce.hr> writes:
"John Reimer" <jjreimer telus.net> wrote in message
news:c6137v$vh9$1 digitaldaemon.com...
 I'm a C++ programmer interested in switching to D, however I dislike not


 cin and cout in D.

 I understand that the << and >> operators are out of question, but since


 eliminated the need for a -> operator couldn't you just use <- and ->


 streaming?

 int i;
 cin -> i;
 cout <- "i is " <- i <- endl;

 That would call cin.opStreamIn and cout.opStreamOut ... bad idea?

 -Mike

<< and >> are not out of the question, just likely not preferred by some

Yes they are (unfortunatelly) out of the questions because the order of chained << or >> isn't defined :(
 programmers (probably the reason this discussion doesn't explore them:
 they're looking for a better way).  The DSC.io project provides these
 C++-style stream operators as well as a different variation.  It's the
 programmers choice as to which to use in an application.  This very
 nicely implemented library is being discussed at www.dscource.org, and I
 believe is close to beta access so that others can play with it (I'm
 really, really hoping ;-) ).

Apr 19 2004
parent reply John Reimer <jjreimer telus.net> writes:
 
 Yes they are (unfortunatelly) out of the questions because the order of
 chained << or >> isn't defined :(
 

Are we talking about a different implementation? I'm just saying that it must be possible to do in D. Kris's DSC.io library does this Stdout << x << "this is a test" << y << Stdout.newline; ... and it works flawlessly. Am I missing something?
Apr 19 2004
parent reply John Reimer <jjreimer telus.net> writes:
John Reimer wrote:

 Yes they are (unfortunatelly) out of the questions because the order of
 chained << or >> isn't defined :(

Are we talking about a different implementation? I'm just saying that it must be possible to do in D. Kris's DSC.io library does this Stdout << x << "this is a test" << y << Stdout.newline; ... and it works flawlessly. Am I missing something?

Sorry, where x and y are int or some other numerical type.
Apr 19 2004
parent reply "Ivan Senji" <ivan.senji public.srce.hr> writes:
"John Reimer" <jjreimer telus.net> wrote in message
news:c616ir$16o5$2 digitaldaemon.com...
 John Reimer wrote:

 Yes they are (unfortunatelly) out of the questions because the order of
 chained << or >> isn't defined :(

Are we talking about a different implementation? I'm just saying that it must be possible to do in D. Kris's DSC.io library does this Stdout << x << "this is a test" << y << Stdout.newline; ... and it works flawlessly. Am I missing something?

Sorry, where x and y are int or some other numerical type.

I have also written a class that can be used like that (i will have to check it out to see how it works for classes) But the problem is that someone on this newsgroup said that the order of execution of chained << is implementation specific and code shouldn't be written that depends on this order. I'm not sure if this is true but it is what i read!
Apr 19 2004
parent reply Mike <Mike_member pathlink.com> writes:
Hmm ... I thought it would be out of discussion because in D things like having
the << operator working as streaming AND shifting operator should be avoided.
Therefore I thought using <- and -> could be a good idea. Introducing new
operators with defined behaviour wouldn't be that bad.

Anyway, after being a lurker here for a couple of weeks and being interested in
D I just wanted to express my wish for something similar to cin/cout in D - I'll
have a look at the classes on dsource. You know, I'd certainly like to get rid
of that stupid printf once and for all, really :-)

Good night,
-Mike
Apr 19 2004
parent John Reimer <jjreimer telus.net> writes:
Mike wrote:

 Hmm ... I thought it would be out of discussion because in D things like having
 the << operator working as streaming AND shifting operator should be avoided.
 Therefore I thought using <- and -> could be a good idea. Introducing new
 operators with defined behaviour wouldn't be that bad.
 
 Anyway, after being a lurker here for a couple of weeks and being interested in
 D I just wanted to express my wish for something similar to cin/cout in D -
I'll
 have a look at the classes on dsource. You know, I'd certainly like to get rid
 of that stupid printf once and for all, really :-)
 
 Good night,
 -Mike
 
 

Hey Mike, I brought it up because I realize that some programmers seem to have a real bond with the << and >> operators for stream use, especially when they come from C++ (I can't stand this use of shift operators myself). DSC.io allows use of them on both linux and windows. The library also provides an alternative method that I prefer. The other method is basically a form of multiple function calls. You'll have to see it. These methods could likely be improved upon, but it's nice just to know that we have something other than printf and <<, >>. There is not much documentation for the project yet other than in-source comments and sample unittest code which sufficient for the most part. The author, Kris, is getting ready to release the source at www.dsource.org soon.
Apr 19 2004
prev sibling next sibling parent reply Ben Hinkle <bhinkle4 juno.com> writes:
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: 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 D/26932 was what I thought Manfred was talking about with "type-safe variable arguments" since it allows vararg style calls with type checking.
Apr 18 2004
next sibling parent reply Vathix <vathix dprogramming.com> writes:
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
Apr 18 2004
parent Ben Hinkle <bhinkle4 juno.com> writes:
 All right, good point.
 So
     foo("hello"; " world");
 would be at least
     foo("hello");
     foo(" world");
 I like it..
 Sorry about my post.

Ack - I didn't mean to imply your idea was a bad one. I just don't think it should be called "variable arguments". Whether a semi-colon or $ or something else is used is somewhat secondary. Heck, back in Walter's original thread there were probably other suggestions - well, those who read closely can find I suggested the syntax foo[a,b,c] D/19001 So you see I think the general idea is just swell. -Ben
Apr 19 2004
prev sibling parent Manfred Nowak <svv1999 hotmail.com> writes:
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:
   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
    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!
Apr 18 2004
prev sibling parent "Scott Egan" <scotte tpg.com.aux> writes:
I know I'm going to get shot for this but...

Why don't we just byte the bullet and allow the opCat to be used, eg

steram.writeLine("Fred was here in: " ~ date ~ ". He has been here " ~ n ~ "
times before.");

Don't hit me too hard.


"Vathix" <vathix dprogramming.com> wrote in message
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. 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

Apr 19 2004