Matthew Wilson wrote:

>>I can see tilde being confused with the array concatenation operator.
> 
> Indeed. That is one of the objections to it
> 

Why "confused"? It's actually the maning of it!
Look. If you have an output, you are actually concatenating stuff to it. Especially if it is a file. Or even if it is a console the paradigm works well enough.

It doesn't make so much sense with inputs though. I think we need something like operator : or :: on them, which could also be used for list separation?

Sather uses a notation like this

#OUT + "this " + 123 + " that";

It actually creates an anonymous object of class OUT and calls an add method of it. Considering that adding is Sather's way of concatenating stuff, it's basically the same idea. The operator itself simply does the output, and then passes the OUT further.

-eye

Russ Lewis wrote:

> I hear you, but I don't think that atomic writes are a big requirement for a general-purpose formatted I/O routine.  Once the routine is in place, you can use the syntax (whatever it happens to be) to build a buffer in memory, something like:
> 
>   Stream str = new BufStream;
>   str <insert the formatting syntax here>;
>   write(file_pointer, str);

IIRC that's what Walter wanted to avoid forcing on the user, for efficiency reasons. He wants whatever system D has to be at least as efficient as printf. Not a basic requierement for the IO system IMHO - that's what the same write is for. A basic requierement is typesafety, extensibility, and ease of use even for beginners. C++ iostreams serve these requierements wonderfully well.

-eye

Ilya Minkov wrote:
>> I hear you, but I don't think that atomic writes are a big requirement for a general-purpose formatted I/O routine.  Once the routine is in place, you can use the syntax (whatever it happens to be) to build a buffer in memory, something like:
>>
>>   Stream str = new BufStream;
>>   str <insert the formatting syntax here>;
>>   write(file_pointer, str);
> 
> 
> IIRC that's what Walter wanted to avoid forcing on the user, for efficiency reasons. He wants whatever system D has to be at least as efficient as printf. Not a basic requierement for the IO system IMHO - that's what the same write is for. A basic requierement is typesafety, extensibility, and ease of use even for beginners. C++ iostreams serve these requierements wonderfully well.


I just had an idea to create an atomic version of the proposed print with the same syntax.

Couldn't the first atomicPrint call return an auto object (like the BufStream mentioned above) that itself works in the same way as the proposed StdIO object? It would accumulate the following print calls and output the resulting string when its destructor is called. Essentially this would be the same as using a temporary Stream object, except that the user would not have to create it explicitly.

Not sure whether auto-objects can be returned from a function, though. My intuition tells me probably not, but I'll would have to try it out...

Hauke

Can you expand on this?  Is this an issue particular to your compiler implementation, or something else?

Walter wrote:
> "Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message
> news:boecta$1kbb$1@digitaldaemon.com...
> 
>>What about this syntax:
>>
>>stdout ~ "asdf" ~ ("%d", foo);
>>
>>Then, the class would have multiple overloaded overloadings of the ~
>>operator.
> 
> 
> Unfortunately, the way overloading works, I don't see how I could make () be
> a parameter list rather than a parenthesized expression.

What about C#'s

MessageBox.Show("NumTwo is {1} and NumOne {0} and both are {0}{1}", NumOne,
NumTwo);


"Sean L. Palmer" <palmer.sean@verizon.net> wrote in message news:boe3nb$16a7$1@digitaldaemon.com...
> What is so evil about it?
>
> What is more evil:
>
> Pascal:   WriteLn("foo", ' ', bar);
> C:  printf("%s%c%i\n","foo",' ',bar);
> C++:  cout << "foo" << ' ' << bar << endl;
> BASIC:  print "foo", " ", %bar, chr(13)
>

In general, a~b is overloaded by looking at the types of a and the types of b. The type of a here is Stdout. The type of b, however, is the type of foo. That isn't going to use the overload of ().

"Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:bogq3g$21fv$1@digitaldaemon.com...
> Can you expand on this?  Is this an issue particular to your compiler implementation, or something else?
>
> Walter wrote:
> > "Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:boecta$1kbb$1@digitaldaemon.com...
> >
> >>What about this syntax:
> >>
> >>stdout ~ "asdf" ~ ("%d", foo);
> >>
> >>Then, the class would have multiple overloaded overloadings of the ~ operator.
> >
> >
> > Unfortunately, the way overloading works, I don't see how I could make
() be
> > a parameter list rather than a parenthesized expression.
>

"Sean L. Palmer" <palmer.sean@verizon.net> wrote in message news:boe65h$19t4$1@digitaldaemon.com...
> Any function that returns itself should work like that, but how the heck would you specify the signature of a function that returns itself?!?

You can't. But you *can* make it work with a so-called function object, which is an object with the () operator overloaded. This works now in D.

"Matthew Wilson" <matthew-hat@-stlsoft-dot.-org> wrote in message news:bocre8$2avm$1@digitaldaemon.com...
> I take it that the reason you want to use it is because it will do an
atomic
> write with a result of all the individual expressions?

I like it because it can work without double buffering of the intermediate results. It can be as efficient as printf().

"Helmut Leitner" <helmut.leitner@wikiservice.at> wrote in message news:3FA9F16C.9DF16013@wikiservice.at...
> Walter wrote:
> > I can make all that work, so the question is do people like the ()() approach, or does it just stink? Andy suggests using ~ instead, that certainly has an appeal, but I'm a bit concerned though about sinking
into
> > the C++ << quagmire <G>.
> I dislike both, especially the ~.

Ok.

> If you use the ()() syntax, then it must be a general language feature,
> that can be used for any function, e. g.
>
>    MoveTo(x1,y1);
>    DrawTo(x2,y1)(x2,y2)(x1,y2)(x1,y1);
>
> If it is that way, it may be ok. It won't hurt, if it isn't used with io
in the end.
> If it is only usable with opCall, then it is an ugly hack.

It won't work at all with functions, but it will work with function objects
(i.e. opCall).

> On the other hand it doesn't solve the inefficiency problem of "C++ <<",
> effecitivly producing a flood of
>    func(this,fmt[,type])
> calls.

I'm not sure why C++'s way fares so poorly. What it won't need to do is have a specialized parser for printf's format string, which takes time.

> And it is not searchable.

It is by searching for 'stdout'.

> And what is the advantage over:
>    stream.print(...)(...)(...);
> ?

()() won't work with plain old functions.

> Even if you do this, these are still open problems
>   - to pass a variable number of arguments safely

Use (var1)(var2)(var3) etc.

>   - to get a generic interface to pass
>        - any arry                                             =>
ArrayInfoStruct
>        - any primitive (now "Type", should be "Prim[itive]")  =>
PrimInfoStruct
>        - any object, array or primitive                       =>
TypeInfoStruct
>
> It would be no good to fix the io problem without taking these into account.

Yes, that needs work.

I'm not buying into your dogma.

Anyway it's not a global variable, it's a global constant.  Similar to PI or whatever.  Are you saying those are always bad too?

Sean

"Matthew Wilson" <matthew-hat@-stlsoft-dot.-org> wrote in message news:bod14n$2ka4$1@digitaldaemon.com...
> I'm sorry, but I think the introduction of global variables purely for syntactic sugaring is a slippery slope that none of us will like hitting
the
> bottom of.
>
> In general, if you need global variables, your design is flawed.