December 11, 2005
>> oh no - here we go... readonly arrays again. ;-)
>
> Nope ... but then, do you find it acceptable the D library returns access to shared internals? ;-)

My opinions were expressed in the previous threads.

In case other people are wondering what threads those are check out the archives during June/July with titles involving words like COW, immutable, readonly and the Round I to VII threads.

I also found the thread I started about passing optional scratch buffers to toString: http://www.digitalmars.com/d/archives/digitalmars/D/28249.html There were no replies so I assumed people were happy with the GC impact of std.string and friends.


December 11, 2005
Ben Hinkle wrote:
>>  Still, Mango is quite a bit more flexible than writef and that it doesn't allocate memory is a huge bonus.  Personally, I'd like to have both options available.
> 
> I can't see where writef allocates memory - though I haven't looked all that hard. Can someone point out what use cases allocate?
> Also what flexibility are you referring to? 

I don't think writef does allocate memory, though Object.toString() is likely to do so, which is how writef prints objects.  So far as flexibility is concerned, writef is great for writing formatted data to the console, to a file, or to another string, but it's fairly common in large applications that I will want to control formatting of objects based on stream characteristics, handle parsing of input data in a similar fashion, make writing to a socket the same as writing to a file (which I suppose it is in Unix), etc.  While this can all be accomplished via writef/readf, it's not really what they were designed for IMO.  But writef is my tool of choice for console IO and such.  You just can't beat the usability of a one-line function call, which Mango doesn't allow out of the box (though wrappers could do this easily enough).


Sean
December 11, 2005
"Sean Kelly" <sean@f4.ca> wrote in...
[snip]
> for IMO.  But writef is my tool of choice for console IO and such.  You just can't beat the usability of a one-line function call, which Mango doesn't allow out of the box (though wrappers could do this easily enough).

That's a small misconception, since mango.io does have out-of-the-box one-line functions for console support. There's were a number of examples earlier, though they likely were lost amid the sea of unrest :-)


December 11, 2005
Kris wrote:
> "Sean Kelly" <sean@f4.ca> wrote in...
> [snip]
>> for IMO.  But writef is my tool of choice for console IO and such.  You just can't beat the usability of a one-line function call, which Mango doesn't allow out of the box (though wrappers could do this easily enough).
> 
> That's a small misconception, since mango.io does have out-of-the-box one-line functions for console support. There's were a number of examples earlier, though they likely were lost amid the sea of unrest :-)

Ah nice.  I only read a few of the posts in the last thread :-)


Sean
December 11, 2005
"Sean Kelly" <sean@f4.ca> wrote ...
> Ah nice.  I only read a few of the posts in the last thread :-)

(* splutter *)

:-)


December 13, 2005
"Manfred Nowak" <svv1999@hotmail.com> wrote in message news:Xns9727D45B325B1svv1999hotmailcom@63.105.9.61...
> 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.

I've been intending for a while now to revise that to make the order of evaluation explicit. The undefined order of evaluation does not offer many benefits, and causes a lot of headaches.

But there are two different things here: order of evaluation, and operator precedence. D operator precedence is clearly defined. For example:

    a + b + c

is defined to be:

    (a + b) + c

There is no ambiguity. The order of evaluation ambiguity comes from the order a, b, and c are evaluated. For example, for:

void a() { writefln("a"); }
void b() { writefln("b"); }
void c() { writefln("c"); }
...
a() + b() + c()

may output one of:

abc
acb
bac
bca
cab
cba


December 13, 2005
"BCS" <BCS_member@pathlink.com> wrote in message news:dnctp1$k9k$1@digitaldaemon.com...
> In article <gf10ceogj4nu.1k0swchr1kpfj.dlg@40tude.net>, Derek Parnell
says...
> >I guess that a statement such as
> >
> >    b + c + d;
> >
> >could evaluate to
> >
> >    b.opAdd(c).opAdd(d)

Operator precedence requires this evaluation.

> >or
> >
> >    d.opAdd(c).opAdd(b)

No.

> >but once the evaluation was set, the execution would proceed in left to right order.

No, *that* is currently undefined. It is currently undefined whether b, c, or d is evaluated first. The operator precedence, however, *is* nailed down.

> the order of evaluation can make a difference even without side effects
> Example (contrived):
>
> class A { B opAdd(C);   A opAdd(A) };
> class C { C opAdd(C);   A opAdd(B) };
> class B {  };
>
> A a;
> B b;
> C c;
>
> auto a2 = a + (b + c);  // a2 is A

Correct.

> auto c2 = (a + b) + c;  // c2 is C

This will fail, as there is no match for (a + b).

> auto q  = a + b + c;    // q is A or C??

It will fail, because it parses as (a+b)+c which has no match for (a+b).


December 13, 2005
Walter Bright wrote:
> "BCS" <BCS_member@pathlink.com> wrote in message
> news:dnctp1$k9k$1@digitaldaemon.com...
> 
>>In article <gf10ceogj4nu.1k0swchr1kpfj.dlg@40tude.net>, Derek Parnell
> 
> says...
> 
>>>I guess that a statement such as
>>>
>>>   b + c + d;
>>>
>>>could evaluate to
>>>
>>>   b.opAdd(c).opAdd(d)
> 
> 
> Operator precedence requires this evaluation.
> 
> 
>>>or
>>>
>>>   d.opAdd(c).opAdd(b)
> 
> 
> No.
> 
> 
>>>but once the evaluation was set, the execution would proceed in left to
>>>right order.
> 
> 
> No, *that* is currently undefined. It is currently undefined whether b, c,
> or d is evaluated first. The operator precedence, however, *is* nailed down.
> 
> 
>>the order of evaluation can make a difference even without side effects
>>Example (contrived):
>>
>>class A { B opAdd(C);   A opAdd(A) };
>>class C { C opAdd(C);   A opAdd(B) };
>>class B {  };
>>
>>A a;
>>B b;
>>C c;
>>
>>auto a2 = a + (b + c);  // a2 is A
> 
> 
> Correct.
> 
> 
>>auto c2 = (a + b) + c;  // c2 is C
> 
> 
> This will fail, as there is no match for (a + b).
> 
> 
>>auto q  = a + b + c;    // q is A or C??
> 
> 
> It will fail, because it parses as (a+b)+c which has no match for (a+b).
> 
> 
oops, my bad, it was supposed to be:

class A { A opAdd(A);   C opAdd(B);   B opAdd(C); };
class B { C opAdd(A);   B opAdd(B);   A opAdd(C); };
class C { B opAdd(A);   A opAdd(B);   C opAdd(C); };

(I got lazy and didn't want to type all of them out)

As to a+b+c being unambiguous, I can't find the rules that make that true. Could you please point me to them?
December 13, 2005
"BCS" <BCS_member@pathlink.com> wrote in message news:dnn794$1psk$1@digitaldaemon.com...
> As to a+b+c being unambiguous, I can't find the rules that make that true. Could you please point me to them?

It's implicit in the grammar for AddExpression's.


December 13, 2005
Walter Bright wrote:
> "BCS" <BCS_member@pathlink.com> wrote in message
> news:dnn794$1psk$1@digitaldaemon.com...
> 
>>As to a+b+c being unambiguous, I can't find the rules that make that
>>true. Could you please point me to them?
> 
> 
> It's implicit in the grammar for AddExpression's.
> 
> 

I just reread that, and I don't see it.

(I'm looking at http://www.digitalmars.com/d/expression.html#AddExpression , is this the right place )