I've just seen in one  Mango example:

Stdout (CR) ("files:") (CR);

What should it mean?
??? Stdout(CR,"files:",CR) ???

Thanks,
Tamás

P.S: Some special possibilities of syntax are not intended for making
sources unreadable ...
Ex.: "a[--b]|=(c=(25+(--d)))" could be legal in C, but for what? ;-)

"MIcroWizard" <MIcroWizard_member@pathlink.com> wrote in message news:dnbut2$17pk$1@digitaldaemon.com...
> I've just seen in one  Mango example:
>
> Stdout (CR) ("files:") (CR);

I haven't used Mango, but I bet it does this:

class SomeOutputStream
{
    SomeOutputStream opCall(whatever)
    {
        ....  // outputs the whatever to the stream buffer
        return this; // important
    }
}

SomeOutputStream Stdout = new SomeOutputStream();

That way, when opCall is called onStdout, you can chain it.  This is because:

1) Stdout(CR) outputs CR (carriage return), then returns itself.
2) Since Stdout(CR) evaluates to Stdout, the next set of parens ("files:")
is evaluated as another opCall.  That again returns Stdout.
3) Same thing again for the second (CR).

So what's really happening is:

Stdout(CR);
Stdout("files:");
Stdout(CR);

It's a clever way of saving space.  If you've ever used C++, and used cout:

cout << "something" << endl;

It's the same thing, but using the << operator instead of the () operator.

Jarrett Billingsley wrote:

> "MIcroWizard" <MIcroWizard_member@pathlink.com> wrote in message news:dnbut2$17pk$1@digitaldaemon.com...
>> I've just seen in one  Mango example:
>>
>> Stdout (CR) ("files:") (CR);
> 
> I haven't used Mango, but I bet it does this:
> 
> class SomeOutputStream
> {
>     SomeOutputStream opCall(whatever)
>     {
>         ....  // outputs the whatever to the stream buffer
>         return this; // important
>     }
> }
> 
> SomeOutputStream Stdout = new SomeOutputStream();
> 
> That way, when opCall is called onStdout, you can chain it.  This is because:
> 
> 1) Stdout(CR) outputs CR (carriage return), then returns itself.
> 2) Since Stdout(CR) evaluates to Stdout, the next set of parens ("files:")
> is evaluated as another opCall.  That again returns Stdout.
> 3) Same thing again for the second (CR).
> 
> So what's really happening is:
> 
> Stdout(CR);
> Stdout("files:");
> Stdout(CR);
> 
> It's a clever way of saving space.  If you've ever used C++, and used cout:
> 
> cout << "something" << endl;
> 
> It's the same thing, but using the << operator instead of the () operator.

In fact that's exactly what it does... This was originally called the "Whisper" notation.  It's rather nice, and I like it.  What do y'all think?

~John Demme

"Jarrett Billingsley" <kb3ctd2@yahoo.com> wrote
> "MIcroWizard" <MIcroWizard_member@pathlink.com> wrote in message news:dnbut2$17pk$1@digitaldaemon.com...
>> I've just seen in one  Mango example:
>>
>> Stdout (CR) ("files:") (CR);
>
> I haven't used Mango, but I bet it does this:
>
> class SomeOutputStream
> {
>    SomeOutputStream opCall(whatever)
>    {
>        ....  // outputs the whatever to the stream buffer
>        return this; // important
>    }
> }

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Yes, that's the general idea. The mango.io package is based partly upon a set of buffered readers and writers. At their heart, the readers and writers support a chaining put/get syntax; similar to how you describe it:

class Writer {
  Writer put (int) {}
  Writer put (char[]) {}
  Writer put (dchar[]) {}
  ...
}

class Reader {
  Reader get (inout int) {}
  Reader get (inout char[]) {}
  Reader get (inout dchar[]) {}
  ...
}

These are aliased both as opCall() and opShl()/opShr(). Obviously, this supports the C++ iostream syntax:

Writer write;

Reader read;

write << 10 << "green bottles";
read >> count >> description.

But, more to the point, it supports what we affectionately call "whisper" syntax in Mango:

 void foo (Writer write, Reader read)
{
    char[] materials;
    int    time, cost;

    write (time) (cost) (materials);
    read  (time) (cost) (materials);
}

Some  nice aspects of this particular approach are:

1) the syntax is identical for both read & write operations. The compiler takes care of providing the appropriate source or target reference. The only different is the verb used (write vs read). You can use the verbs input/output instead, if that rocks your boat :-)

2) it is thoroughly type-safe.

3) default arguments can be passed as part of the call.

4) it is quite efficient. DMD does a fine job optimizing this style of programming.

5) the approach supports an obvious and natural way to be explicit about transcoding (between char/wchar/wdchar content).

6) it is flexible and highly extensible. For example, the syntax is just the same whether you're working with text or binary I/O

7) an empty set of parenthesis maps quite naturally to a "flush" operation :-)

e.g:  write (time) (cost) (materials) ();

8) there's nothing that restricts one from using printf() syntax instead. For example, the text oriented DisplayWriter additionally has print() and println() methods. Stdout is an instance of DisplayWriter.

9) it becomes trivial to map a user-class to the I/O system ~ i.e.

==============
class ContractJob : IWritable, IReadable
{
    char[] materials;
    int    time, cost;

     void write (IWriter output)
    {
        output (time) (cost) (materials);
    }

     void read (IReader input)
    {
        input (time) (cost) (materials);
    }
}

ContractJob job1;
ContractJob job2;

write (job1) (job2) ();
read (job1) (job2);
===============

10) "whisper" is a cool name :-p


You can read more about Mango I/O in the source code, such as here:

http://trac.dsource.org/projects/mango/browser/trunk/mango/io/Buffer.d http://trac.dsource.org/projects/mango/browser/trunk/mango/io/Writer.d http://trac.dsource.org/projects/mango/browser/trunk/mango/io/Reader.d

Kris wrote:
> 
> Yes, that's the general idea. The mango.io package is based partly upon a set of buffered readers and writers. At their heart, the readers and writers support a chaining put/get syntax; similar to how you describe it:
> 
> class Writer {
>   Writer put (int) {}
>   Writer put (char[]) {}
>   Writer put (dchar[]) {}
>   ...
> }
> 
> class Reader {
>   Reader get (inout int) {}
>   Reader get (inout char[]) {}
>   Reader get (inout dchar[]) {}
>   ...
> }
> 
> These are aliased both as opCall() and opShl()/opShr(). Obviously, this supports the C++ iostream syntax:
> 
> Writer write;
> 
> Reader read;
> 
> write << 10 << "green bottles";
> read >> count >> description.
> 
> But, more to the point, it supports what we affectionately call "whisper" syntax in Mango:
> 
>  void foo (Writer write, Reader read)
> {
>     char[] materials;
>     int    time, cost;
> 
>     write (time) (cost) (materials);
>     read  (time) (cost) (materials);
> }

I love the "whisper" syntax.  However, it's worth noting that it's a tiny bit less flexible than the C++ method.  For example, say I want to create a ReaderWriter class.  The C++ method is unambiguous, if confusing:

ReaderWriter rw = new ReaderWriter();

rw << x >> y;

The "whisper" syntax doesn't work in this case, as there's no way to determine whether the user wants to read or write.  That said, the need for "IOStreams" is not terribly common in the average case, though I do personally use this technique quite a bit in C++ (stringstreams, for example).  But then I'm not terribly familiar with the intricacies of Mango.  Is there an easy way around this already?


Sean

John Demme wrote:
[...]
> This was originally called the "Whisper" notation.  It's rather nice, and I like it. What do y'all think?

I do not find it that nice, because the whisper notation restricts the power of D to regular expressions over arguments lists, whereas context free languages over arguments lists are possible.

I have written on that several month ago and proposed to drop this restriction by using

| Stdout (CR; "files:"; CR);

instead of

| Stdout (CR) ("files:") (CR);


Moreover the behaviour of the whisper notation is undefined according to the specs, which clearly state that the order of all expression evaluations are undefined if not explicitely defined---and no definition for the whisper notation is given.

Therefore Mango is not portable at present between compilers. To make it portable instead of "Stdout(CR)("files:")(CR);" Mango should contain

| ((Stdout(CR))("files:"))(CR);

which is probably what is meant. Still I would prefer

| Stdout(CR; "files:"; CR);

or similar which on my opinion is as well more readable as freeing the full power of D.

-manfred

"Sean Kelly" <sean@f4.ca> wrote ...
> I love the "whisper" syntax.  However, it's worth noting that it's a tiny bit less flexible than the C++ method.  For example, say I want to create a ReaderWriter class.  The C++ method is unambiguous, if confusing:
>
> ReaderWriter rw = new ReaderWriter();
>
> rw << x >> y;
>
> The "whisper" syntax doesn't work in this case, as there's no way to determine whether the user wants to read or write.  That said, the need for "IOStreams" is not terribly common in the average case, though I do personally use this technique quite a bit in C++ (stringstreams, for example).  But then I'm not terribly familiar with the intricacies of Mango.  Is there an easy way around this already?


Mango.io does that by sharing the buffer between reader and writer:

auto read = new Reader (commonBuffer);
auto write = new Writer (commonBuffer);

write (x);     // or write << x;
read (y);     // or read >> y;

It's a bit more explicit than the C++ version. One might also use the Buffer by itself for such things, using append() and get() methods, sans any formatting.

In article <Xns9727D45B325B1svv1999hotmailcom@63.105.9.61>, Manfred Nowak says...
>
>John Demme wrote:
>[...]
>> This was originally called the "Whisper" notation.  It's rather nice, and I like it. What do y'all think?
>
>I do not find it that nice, because the whisper notation restricts the power of D to regular expressions over arguments lists, whereas context free languages over arguments lists are possible.
>
>I have written on that several month ago and proposed to drop this restriction by using
>
>| Stdout (CR; "files:"; CR);
>
>instead of
>
>| Stdout (CR) ("files:") (CR);
>
>
>Moreover the behaviour of the whisper notation is undefined according to the specs, which clearly state that the order of all expression evaluations are undefined if not explicitely defined---and no definition for the whisper notation is given.
>
>Therefore Mango is not portable at present between compilers. To make it portable instead of "Stdout(CR)("files:")(CR);" Mango should contain
>
>| ((Stdout(CR))("files:"))(CR);
>
>which is probably what is meant. Still I would prefer
>
>| Stdout(CR; "files:"; CR);
>
>or similar which on my opinion is as well more readable as freeing the full power of D.
>
>-manfred

I'd hate to have you re-explain yourself on this thread, but I simply do not understand your argument.  May I ask that you please indulge this poor fool? :)

To me, the line:
# Stdout (CR) ("hello") (" ") ("world") (CR);

Aliases to nothing other than:
# Stdout.opCall(CR).opCall("hello").opCall(" ").opCall("world").opCall(CR);

I can't see any kind of restriction on the language itself; unless you're talking about the potential for future behaviors?  In that case I'd have to agree, but that decision was made a long time before this kind of use for opCall was conceived.

- EricAnderton at yahoo

pragma wrote:
> 
> I'd hate to have you re-explain yourself on this thread, but I simply do not
> understand your argument.  May I ask that you please indulge this poor fool? :)
> 
> To me, the line:
> # Stdout (CR) ("hello") (" ") ("world") (CR);
> 
> Aliases to nothing other than:
> # Stdout.opCall(CR).opCall("hello").opCall(" ").opCall("world").opCall(CR);

Agreed.  Where does expression ordering ambiguity come into play here?


Sean

On Fri, 9 Dec 2005 20:22:59 +0000 (UTC), pragma wrote:

> To me, the line:
> # Stdout (CR) ("hello") (" ") ("world") (CR);
> 
> Aliases to nothing other than:
> # Stdout.opCall(CR).opCall("hello").opCall(" ").opCall("world").opCall(CR);

As the sequence of evaluation is not defined (in the general case), this
might output ...

  world hello

in some implementations of D.

-- 
Derek Parnell
Melbourne, Australia
10/12/2005 7:34:02 AM