Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples

[Jacob Carlborg]

On 2012-09-25 00:28, bearophile wrote:


(||)
(|1|)
(|1, 2|)
(|1, 2, 3|)


What about:

||
|1|
|1, 2|


--
/Jacob Carlborg

Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples

[Jacob Carlborg]

On 2012-09-25 03:19, ixid wrote:

What would a special case where the first level of tuple (with higher
levels being tuples in tuples) didn't require parens break? This would
be a beautiful syntax:

auto a = 1, 2; // A tuple of two ints

int, string fun(double, double d) {
 return cast(int) (d[0] * d[1]), "hello";
}

auto a, b = 1, 2; // Two ints
auto a = fun(1.0, 1.0); // Tuple of 1 and "hello".
auto a, b = fun(1.0, 1.0); // An int and a string.



I like this one.

--
/Jacob Carlborg

std.range should support recursion (Was: One-line FFT, nice!)

[Mehrdad]

I thought I'd take the opportunity to point this out:

The one-line FFT in D is pretty inefficient because it allocates 
memory.


If std.range supported recursion (i.e. by providing a different 
implementation for ranges that can be implemented without 
creating new times, i.e. Stride of Stride == Stride), then it 
would make the library a lot more usable and less bloated.



My one-line FFT illustrates it perfectly:


import std.algorithm;
import std.math;
import std.range;
typeof(R.init.stride(0)) dft(R)(R v)
{
return v.length > 1 ?
	  (p => chain(map!(q => q[0] + q[1])(p), map!(q => q[0] - 
q[1])(p)))

  (zip(dft(v.stride(2)),
   map!(p => p[1] * expi(p[0] * -2 * PI / v.length))
   (zip(iota(v.length / 2), dft(v.drop(1).stride(2)) : v;
}
void main() { dft([1.0, 2, 3]); }


Side note: the error messages are also hard to read.

Re: std.range should support recursion (Was: One-line FFT, nice!)

[Mehrdad]

On Tuesday, 25 September 2012 at 08:21:39 UTC, Mehrdad wrote:

without creating new times



new types**

Re: References in D

[Mehrdad]

On Tuesday, 18 September 2012 at 19:30:24 UTC, Simen Kjaeraas 
wrote:
On Tue, 18 Sep 2012 16:56:31 +0200, Mehrdad 
 wrote:


On Saturday, 15 September 2012 at 23:28:36 UTC, Walter Bright 
wrote:
I wouldn't worry about it. I suspect that most C++ 
programmers think that references cannot be null.



Yeah, they can't be null _legally_.

Kind of like how in D you can't strip away const _legally_.

But the compiler doesn't complain if you don't obey the rules.


Well, D at least makes you jump through hoops to strip away 
const,



What does this have to do with const?



while C++ assumes that however stupid the thing you seem to be 
doing is, you probably intended to be that stupid.



Uhm, pardon? Not only is it irrelevant, it's also wrong:
It's harder to do that in C++ than in D.

In C++ you need const_cast (you shouldn't be using a C-style 
casts at all).


In D all you have is cast(), and it's damn easy to strip away 
const, especially when dealing with templates. And the compiler 
doesn't complain either!

Re: References in D

[Mehrdad]

On Tuesday, 25 September 2012 at 09:00:39 UTC, Mehrdad wrote:

What does this have to do with const?
...
Not only is it irrelevant, it's also wrong:
It's harder to do that in C++ than in D.



My bad, it's not irrelevant, I misunderstood your reasoning.

It's still wrong though. :)

Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples

[Don Clugston]

On 24/09/12 17:19, Andrei Alexandrescu wrote:

On 9/24/12 4:17 AM, Don Clugston wrote:

Regarding the comma operator: I'd love to deprecate it, but even if we
don't, could we at least ensure that this kind of rubbish doesn't
compile:

void main()
{
int x;
x > 0, x += 5;
}

At present, because comma expressions are expressions, not statements,
the "x > 0" doesn't generate a "statement has no effect" error, despite
the fact that it is meaningless and gets completely discarded.


Interesting. The comma operator is probably the only one in which an
expression is evaluated only for the sake of its side effects. So
eliminating the comma operator would just get rid of that case by design.


Yes. Comma is a special case in a number of ways.


Of course, there's always the option of adding more checks or rewriting
the comma operator from "expr1, expr2, expr3" to "{ expr1; expr2; return
expr3; }()".


We hit this one often in real-world code. On German keyboards , and ; 
are on the same key, so it's a fairly easy typo. I don't think it 
happens as often when using a US keyboard.

Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples

[deadalnix]

Le 24/09/2012 17:29, Andrei Alexandrescu a écrit :

On 9/24/12 11:23 AM, Eldar Insafutdinov wrote:

On Monday, 24 September 2012 at 14:52:21 UTC, Steven Schveighoffer wrote:

Without any research or investigation, what about using a different
set of delimiters for tuples? Like {1,2,3}


 and exactly the syntax I was going to propose!


Assume you had this syntax working today. So instead of writing
"tuple(a. b. c)" you write "{ a, b, c }". To what extent would your code
be better? (Honest question. Don't forget that adding the => syntax for
lambda /did/ make for better code.)


Andrei


{} is often harder to disambiguate then () with current D syntax.

Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples

[deadalnix]

Le 25/09/2012 01:59, Andrej Mitrovic a écrit :

On 9/25/12, Steven Schveighoffer  wrote:

However, this brings up another issue, what about porting C code?  All of
a sudden c style casts are no loner errors, but are type tuples!


I think they're still errors:

int x = (int)foo;

Maybe the compiler could figure out if a cast was attempted rather
than a tuple, and could print out the ol' "Can't use C shenanigans in
D" error.


It will, because it is trying to parse an expression here, not a 
declaration.

Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples

[deadalnix]

Le 24/09/2012 17:24, Andrei Alexandrescu a écrit :

On 9/24/12 9:27 AM, Philippe Sigaud wrote:

On Mon, Sep 24, 2012 at 12:46 PM, Nick Sabalausky
 wrote:


That said, I'm not necessarily opposed to the strict separation if we
had a good candidate for built-in tuple literal syntax. But *if* the
best we have is parens (and maybe there *is* something better?) then
maybe this would be an acceptable way to achieve it?


If the problems in DIP 19 are deemed mostly syntactic (1- and 0-
element tuples), then maybe *for once* a simple syntax change could
solve them? I know syntax proposals are a dime a dozen in this
newsgroup, but why not here, to avoid the ((1)) problem?

For example choosing { 1, 2} to represent a tuple? { } blocks in D
enclose semi-colon terminated declarations or expressions, but here
it's enclosing comma-separated expressions. And, since { } is probably
dangerous without a completly integrated type systems giving a type to
all expressions ( (){} anyone?) , why not use (| 1, 2 |), or whatever
syntax strikes our collective fancy? (I propose *not* to use< ,>)

Then, the compiler has to change the way it prints its internal tuple,
to follow the new syntax.


Ie:

// (3) is polysemous: Either int or (int)
int a = (3); // Normal value
(int) b = (3); // One-element tuple
auto c = (3); // Default to normal "int"?


For the third case, I'd say it defaults to a tuple. But then again,
using another syntax solves this problem.

auto c = (| 3 |); // or c = { 3 };


I think my main problem with this is that I'm perfectly happy with the
baseline, which has "tuple(" as the left delimiter and ")" as the right
delimiter. I'd be more excited to invent notation if there was
overwhelming or at least considerable evidence that the notation
considerably helps certain use cases, or is very frequent. As things
are, I'd be quite "meh" about suddenly adding lenses.

Andrei


Clearly, crating a tuple that way isn't the issue. tuple() is ok.

Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples

[deadalnix]

Le 24/09/2012 17:55, Philippe Sigaud a écrit :

On Mon, Sep 24, 2012 at 5:24 PM, Andrei Alexandrescu
  wrote:


I think my main problem with this is that I'm perfectly happy with the
baseline, which has "tuple(" as the left delimiter and ")" as the right
delimiter.


I found it a bit long compared to other languages in the beginning,
but I've been using them heavily since you added them to Phobos and
I'm now quite happy with them. I even like the .expand thingy.


(I have a few nitpicks, about std.typecons.tuple, but those would be
the subject of another thread)



I'd be more excited to invent notation if there was overwhelming
or at least considerable evidence that the notation considerably helps
certain use cases, or is very frequent. As things are, I'd be quite "meh"
about suddenly adding lenses.


OK.

One standard use for tuples is assignment:

a,b = someTuple;  // a and b already exist in this scope
auto (c,d) = someTuple; // creates c and d

and similar variations, which Phobos' tuples do not provide.


And the auto flatten stuff is really weird, and sometime get into the way.

Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples

[deadalnix]

Le 25/09/2012 01:39, Andrei Alexandrescu a écrit :

On 9/24/12 6:28 PM, bearophile wrote:

Timon Gehr:


My bikeshed is colored one of these:

(:1,2)
(|1,2)



At that point you might as well just use

import std.typecons : q = tuple, Q = Tuple;

Q!(int, int) foo(){
return q(1, 2);
}

If built-in tuples are not going to look like

(1, 2)

then imho we might as well leave them out,


But the banana syntax doesn't look bad:

(||)
(|1|)
(|1, 2|)
(|1, 2, 3|)


tuple()
tuple(1)
tuple(1, 2)
tuple(1, 2, 3)

also arguably enjoys the same advantages and in fact is much more
intuitive. Like, totally intuitive. Like, it says "tuple" to create a
tuple. And one advantage is, there's never ever going to be butt jokes
about tuple() as there'd be with "(||)".



The problem with tuple() isn't its syntax, but what you can or can't do 
with the resulting tuple.

Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples

[deadalnix]

Le 25/09/2012 03:19, ixid a écrit :

What would a special case where the first level of tuple (with higher
levels being tuples in tuples) didn't require parens break? This would
be a beautiful syntax:

auto a = 1, 2; // A tuple of two ints

int, string fun(double, double d) {
return cast(int) (d[0] * d[1]), "hello";
}

auto a, b = 1, 2; // Two ints
auto a = fun(1.0, 1.0); // Tuple of 1 and "hello".
auto a, b = fun(1.0, 1.0); // An int and a string.



It can get pretty confusing with , separated declarations :

int a, b = 3;

or worse :

int a, int b = foo();
-->
(int a, int b) = foo();
  or
int a, (int b = foo());

and it gets worse with int a, auto b = foo();

But I do agree that this is really nice in many places.

Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples

[deadalnix]

Le 25/09/2012 09:11, Jacob Carlborg a écrit :

On 2012-09-25 00:28, bearophile wrote:


(||)
(|1|)
(|1, 2|)
(|1, 2, 3|)


What about:

||
|1|
|1, 2|



Yeah and why not þ1, 2þ or ŀ1, 2ŀ ?

maybe ↓1, 2↓ is better ?

or « 1, 2 » (this one at least is readable).

Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples

[deadalnix]

Le 24/09/2012 16:59, foobar a écrit :

I'm a bit confused about what is specifically proposed here:
- Is the suggestion to limit tuples to >1 elements? *This* I'm against
for practical as well as completeness reasons. Andrei already provided
one example, and another would be a proper unit type. e.g.
void foo(int a) {}
void bar (int b) { return foo(b); }
- Is the suggestion to allow implicit conversion between (T) and T?
This brings almost no benefit - (you save two keystrokes?) and adds a
special case to the language. The added complexity really does not
justify this.


In fact, they don't need to unpack only for 1 element tuples, but this 
is the tricky case. Today, tuples auto unpack on function call for 
instance :


auto t = tuple (1, 2);
foo(t); // call foo(int, int)

Re: [OT] C# scores again for game development

[Jonas Drewsen]

On Sunday, 23 September 2012 at 22:09:19 UTC, Paulo Pinto wrote:
On Sunday, 23 September 2012 at 20:49:54 UTC, Nick Sabalausky 
wrote:

On Sun, 23 Sep 2012 19:08:16 +0200
"Paulo Pinto"  wrote:

On Sunday, 23 September 2012 at 16:14:33 UTC, Jonas Drewsen 
wrote:
> On Sunday, 23 September 2012 at 15:06:51 UTC, Paulo Pinto 
> wrote:
>> Since this is one area where D could eventually replace 
>> C++, I've decided to post it here.

>>
>> So after Sony decided to make use of C#/Mono for the PS 
>> Vita SDK, Nintendo has decided to do the same by 
>> supporting Unity for the new Wii U.

>>
>> 
http://www.marketwire.com/press-release/unity-technologies-enters-extensive-agreement-with-nintendo-to-support-wii-u-1703600.htm
>>
>
> Note that it is only the scripting part of Unity that is 
> C#/Mono. The core engine and editor is C++.

>
> /Jonas

I know.


I didn't. That's very interesting to hear.


The core engine is C++.

Mono takes care of allowing any .NET language to be used as 
scripting language, with C#, JavaScript and Boo having the main 
roles, while compiling them AOT to native code as well.


UnityScript - not Javascript. They resemble each other but 
UnityScript has classes and supports static types etc. Much 
better in my opinion.


/Jonas

Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples

[bearophile]

deadalnix:

The problem with tuple() isn't its syntax, but what you can or 
can't do with the resulting tuple.


See my first posts in this thread :-)

On the other hand it's handy to have a compact syntax for 
something you use often 
(http://en.wikipedia.org/wiki/Zipf%27s_law ).


Bye,
bearophile

Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples

[Jacob Carlborg]

On 2012-09-25 12:05, deadalnix wrote:


It can get pretty confusing with , separated declarations :

int a, b = 3;


I wouldn't complain if that became illegal.

--
/Jacob Carlborg

Re: Function prototype + definition in the same file

[bearophile]

Manu:

I have a fairly comprehensive binding solution which automates 
the work in
the case of dynamic linkage, but the problem is the way the 
user defines the functions that exist in the D code.


Maybe there are better ways to solve your problems (even changing 
D language in some ways), and keep avoiding the need of free 
floating ghosts of functions.


Bye,
bearophile

Re: Function prototype + definition in the same file

[Manu]

On 25 September 2012 15:21, bearophile  wrote:

> Manu:
>
>
>  I have a fairly comprehensive binding solution which automates the work in
>> the case of dynamic linkage, but the problem is the way the user defines
>> the functions that exist in the D code.
>>
>
> Maybe there are better ways to solve your problems (even changing D
> language in some ways), and keep avoiding the need of free floating ghosts
> of functions.
>

Can you suggest a more direct approach? Declaring prototypes seems
completely natural, supports all the expected IDE features, and in the
simple/common case (static linkage) requires absolutely no magic voodoo.

Re: reference to 'self' inside a function

[Nick Treleaven]

On 25/09/2012 06:07, Rob T wrote:

This is a little insane, but it works.

int Recurse(int a)
{
if (a <= 1)
   return 1;
else
// can we replace explicit call to "Recurse"
// with "self" using a mixin or some other means?
//   return a * Recurse(a - 1);
   mixin("return a * mixin(__traits(identifier, __traits(parent,
{})))(a - 1);");
}


enum string self = q{__traits(parent, {})};

int recurse(int a)
{
   if (a <= 1)
  return 1;
   else
  return a * mixin(self)(a - 1);
}

Re: std.range should support recursion (Was: One-line FFT, nice!)

[Andrei Alexandrescu]

On 9/25/12 4:22 AM, Mehrdad wrote:

If std.range supported recursion (i.e. by providing a different
implementation for ranges that can be implemented without creating new
times, i.e. Stride of Stride == Stride), then it would make the library
a lot more usable and less bloated.


I'm not sure I understand this, and it seems I should. Could you please 
explain (perhaps with a simpler example than FFT)?


Thanks,

Andrei

Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples

[Andrei Alexandrescu]

On 9/25/12 6:10 AM, deadalnix wrote:

Le 24/09/2012 16:59, foobar a écrit :

I'm a bit confused about what is specifically proposed here:
- Is the suggestion to limit tuples to >1 elements? *This* I'm against
for practical as well as completeness reasons. Andrei already provided
one example, and another would be a proper unit type. e.g.
void foo(int a) {}
void bar (int b) { return foo(b); }
- Is the suggestion to allow implicit conversion between (T) and T?
This brings almost no benefit - (you save two keystrokes?) and adds a
special case to the language. The added complexity really does not
justify this.


In fact, they don't need to unpack only for 1 element tuples, but this
is the tricky case. Today, tuples auto unpack on function call for
instance :

auto t = tuple (1, 2);
foo(t); // call foo(int, int)


Actually that's not the case. You need to write

foo(t.expand);

(and I think that's a good thing).


Andrei

Re: std.range should support recursion (Was: One-line FFT, nice!)

[Andrei Alexandrescu]

On 9/25/12 4:23 AM, Mehrdad wrote:

On Tuesday, 25 September 2012 at 08:21:39 UTC, Mehrdad wrote:

without creating new times



new types**


Ah, better now. Still it would be great to explain it more :o).

Andrei

Re: [OT] Was: totally satisfied :D

[Steven Schveighoffer]

On Tue, 25 Sep 2012 01:55:54 -0400, Nick Sabalausky  
 wrote:



On Mon, 24 Sep 2012 21:52:05 -0400
"Steven Schveighoffer"  wrote:


There is a master volume control.  It has two volumes, on and off, and
it's called the silent switch ;)



Calling that a master volume control is a stretch.


Yeah I know.  But it's about the closest thing you can get to a physical  
master volume on the iPhone.



>> They aren't?  They make complete sense to me.  You even admit that
>> it makes sense to have find my iphone play its alerts as loud as
>> possible.
>
> No, only the "find iPhone" one. The iPhone has no fucking idea what
> environment I'm in. I *definitely* don't want it screeching "PAY
> ATTENTION TO M" indiscriminately whenever it damn well feels
> like it.

When does it do that?



I thought you were just saying that the iPhone plays it's alerts as
loud as possible?


The only alert which is not played at the set ringer volume that I know of  
is the find-my-iphone alert (which I think you agree makes sense).  All  
the other alerts (alarm, message notification, timer expired, etc.) play  
at the ringer volume.






I just discovered through testing that timer has the same feature as
alarm.  I find that incorrect.  If I have the silent switch enabled,
the timer should just vibrate.

In fact, I don't think there's a way to make the timer "just vibrate"
in any way.  That's counter-intuitive and I will agree with you on
that one.



Yea, see there's just too much "surprise" involved, IMO.


To me, that is not a critical issue.  I've had an iPhone since June of  
2010, and I didn't even realize this until now (and I use my iPhone for  
pretty much everything).  But if you are *looking* for problems, this  
certainly was not as well thought out as the other sounds.



I have seen strange things there, sometimes a photo/video comes in
rotated (I see it pass by the Windows photo import preview), but then
when I look at the photo in Explorer, it's correctly rotated.



I'm looking at the photos on my iPhone through Explorer right now and
aside from the screenshots, the majority of them are either sideways or
upside-down.


Wait, did you *download* them?  Or are you just browsing via the USB  
cable?  When you download them via the camera import feature of Windows (I  
think XP has that), it corrects the rotation.  I have no idea why it waits  
until then.



The bizarre thing is, when I look at them through "Photos" on the
device itself, it actually shows them all correctly. Which means that
the device *knows* how they're supposed to be but doesn't bother to
actually save them correctly.


I don't think the photos are meant to be browsed that way.  See this  
thread here https://discussions.apple.com/message/16514340#16514340


I think explorer must not be using the rotation field (seems odd), but the  
camera import rotates the picture on import.




Doesn't protect the lens though, and it doesn't provide a physical
button which would obviate the need to hijack the volume button. (It
*is* at least a little better than not being able to access the camera
from the lock screen at all.)


Weren't you the one advocating a case?

And the hijacking of the button, as I said before, is a misfeature.  It  
doesn't really hurt, but it's too poorly positioned to be useful IMO.



I have to say, this is one of the better improvements, especially with
those of us who have kids.



Yea, one-size-fits-all design :/


Oh, it was annoying when the kids were doing something cute, and you have  
to type in your code to unlock, then go find the camera app, wait for it  
to load (I think they actually improved the load time too) and by that  
time, it was over.  One of the perks of having a camera on your phone is  
you always have it with you.



That said, I do like to use "kids" as an argument for having an
OS-level "disable software eject" option for optical drives. ;)  "Ok,
I'll just leave that to burn..." Walk away. It finishes and ejects. Kid
waddles by. "Ohh, a pretty shiny object! Should I eat it or flush it?"


Or use it as a frisbee :)  Then you can damage two things at once!


While viewing a photo, tap the screen to bring up the controls.  Click
"Edit" (upper right corner), then you can rotate the photo.  Don't
think you can do the same with a video.

Don't think I agree that an Edit button on the main photo viewing
screen is not realistically discoverable.



I don't see any rotate there:

http://semitwist.com/download/img/shots/IMG_0859.PNG

I just see the "Back" button then...umm "Do a Magic Trick?" (WTF?),
then I'm guessing maybe "Anti-Red-Eye", and...ok, I'm pretty sure that
last one's crop, I remember seeing it in one or two image editing
programs.


The "back button" is the rotate.  I agree it's not very well drawn, it  
should be more like a quarter-turn and less snazzy (just a quarter circle  
arrow would be better).


The button on the top that says "Cancel" is actually the back button.

Besides, I don't t

Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples

[deadalnix]

Le 25/09/2012 13:42, Jacob Carlborg a écrit :

On 2012-09-25 12:05, deadalnix wrote:


It can get pretty confusing with , separated declarations :

int a, b = 3;


I wouldn't complain if that became illegal.



Nor me (it was already confusing and confusable with comma expressions), 
but a hell lot of code rely on comma declarations.

Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples

[deadalnix]

Le 25/09/2012 15:38, Andrei Alexandrescu a écrit :

On 9/25/12 6:10 AM, deadalnix wrote:

Le 24/09/2012 16:59, foobar a écrit :

I'm a bit confused about what is specifically proposed here:
- Is the suggestion to limit tuples to >1 elements? *This* I'm against
for practical as well as completeness reasons. Andrei already provided
one example, and another would be a proper unit type. e.g.
void foo(int a) {}
void bar (int b) { return foo(b); }
- Is the suggestion to allow implicit conversion between (T) and T?
This brings almost no benefit - (you save two keystrokes?) and adds a
special case to the language. The added complexity really does not
justify this.


In fact, they don't need to unpack only for 1 element tuples, but this
is the tricky case. Today, tuples auto unpack on function call for
instance :

auto t = tuple (1, 2);
foo(t); // call foo(int, int)


Actually that's not the case. You need to write

foo(t.expand);

(and I think that's a good thing).


Andrei


OK, my bad. It means that tuple(...) behave differently than T... 
defined tuples.


And both behave differently than Caml or Haskell's tuples.

isn't the time for some unification ? Preferably on how tuples work in 
other languages, except if limitations can be shown and better proposal 
are made (and not include that in D2.xxx).

Re: Function prototype + definition in the same file

[Steven Schveighoffer]

On Tue, 25 Sep 2012 07:53:17 -0400, Manu  wrote:


So I have this recurring pattern, it's really starting to annoy me.
It stems from the fact that a function prototype and the definition can  
not

appear in the same file in D (as it can in C/C++)


Doing this is not illegal.


Eg,

void func(int x); // <-- declaration of function, informs type and
associated names, args, ...

//later
void func(int x) // <-- may be generated with magic (and may use the
prototype declaration for type information as declared by the prototype
above)
{
  ... do stuff
}


This compiles.  Do you have a better case to show the problem?

-Steve

Re: Function prototype + definition in the same file

[Manu]

On 25 September 2012 17:25, Steven Schveighoffer wrote:

> On Tue, 25 Sep 2012 07:53:17 -0400, Manu  wrote:
>
>  So I have this recurring pattern, it's really starting to annoy me.
>> It stems from the fact that a function prototype and the definition can
>> not
>> appear in the same file in D (as it can in C/C++)
>>
>
> Doing this is not illegal.
>
>
>  Eg,
>>
>> void func(int x); // <-- declaration of function, informs type and
>> associated names, args, ...
>>
>> //later
>> void func(int x) // <-- may be generated with magic (and may use the
>> prototype declaration for type information as declared by the prototype
>> above)
>> {
>>   ... do stuff
>> }
>>
>
> This compiles.  Do you have a better case to show the problem?
>

void blah();

void  blah()
{
int x = 0;
}

void f()
{
   blah(); // <- call it
}


W:\project\main\sourcedata\plugins\remedy\modules\test_module.d(38):Error:
function remedy.testmodule.blah called with argument types:
(())
matches both:
remedy.testmodule.blah()
and:
remedy.testmodule.blah()

Obviously, one is just a prototype, and the symbol is resolved within the
local file.

Re: [OT] Was: totally satisfied :D

[H. S. Teoh]

On Mon, Sep 24, 2012 at 09:55:48PM -0400, Nick Sabalausky wrote:
[...]
> > > > The one thing I would rip out of OSX and throw against the wall
> > > > is the mail app.  Its interface and experience is awesome.  But
> > > > it frequently corrupts messages and doesn't properly save
> > > > outgoing mail.  Not good for a mail application.
> > 
> > Ahhh how I love Mutt. ;-)
> > 
> 
> I've been finding Mutt very useful for when I'm ssh'ed into my server
> to create a temporary throwaway address. Doing "mutt -f
> /path/to/mailbox" is so much more convenient than setting up a POP3
> GUI client. I need to learn how to use mutt better though, as I've
> just been fumbling around with it.

Well, mutt's tagline is that it sucks, all MUAs suck, mutt just sucks
less. :-)


> For my usual mailboxes though, I prefer typical GUI desktop clients.
> Unfortunately, I still haven't been able to find one that I like.

Maybe you should write one in D. ;-)

For one thing, having a MIME library in D would be awesome.


> Outlook Express has a bunch of problems (no spellcheck, can't send
> UTF, proprietary storage, etc). Windows Mail won't be an option when I
> move to Linux or upgrade back to XP. Claws mail is just generally
> buggy and never does anything in the background (feels almost like it
> might be purely single-threaded). And I'm not a big fan of Opera and
> don't really want to use a web browser as my desktop mail client.

I'm a big Opera fan, because Opera lets me configure stuff to work the
way I want it to. But I never use it for mail (I don't like using a
browser as an MUA, I think that's just feeping creaturism). And recent
releases of Opera are starting to show signs of instability and
excessive memory consumption, unlike earlier releases, and I'm starting
to wonder if I might want to switch to Firefox...


> I think I might actually try moving to Thunderbird even though I'm
> generally unhappy with Mozilla software/practices, and didn't like it
> last time I tried (for example, it kept trying to
> bold/italic/underline parts of text in my *plaintext* views, and the
> people on the "help" forums just complained that I should shut up and
> like it - which is consistent with what usually happens when I inquire
> about customizing parts of Mozilla's so-called "most customizable
> browser in the world").

... but if it's that unconfigurable, then Opera might just be the lesser
of two evils. I have to admit that I've tried using Firefox as my
primary browser before, and I didn't like it. It's too IE-like for my
tastes.


[...]
> > I find pretty much all GUI mail apps (both webmail and local MUAs)
> > strait-jacketed. Anything that doesn't let you configure mail
> > headers is unusable to me, and HTML by default gets on my nerves so
> > much it's not even funny.
> 
> I never care about mail headers (unless I'm debugging something
> mail-related, which isn't often), but I *ALWAYS* have HTML disabled.
> I'll never use a mail client that doesn't let me turn HTML off. Not
> only do I not want to deal with any tracker-images (or god forbid, JS
> emails), but in my experience "HTML email" just means it's too easy,
> and far too tempting, for other people to make the stuff they send me
> really, really ugly ;) "Just the words, ma'am."
[...]

That's why I liked Markdown. :) Give users _basic_, logical markup that
also just happens to be readable in plaintext that can be sent verbatim
over the wire, and can be optionally written/read in HTML. Email doesn't
need HTML, the only really necessary stuff is a bit of logical markup
for people who find plaintext "too primitive". HTML is overkill.

Not to mention... it's not just the JS or tracker images, but have you
ever been asked to make HTML email newsletters that have to look the
same across the board? Ever looked at the standards for HTML emails?
Haha, fooled you. There is no standard. Every webmail and their
neighbour's open relay have their own conventions for HTML email.
Nothing is compatible.  You can't rely on CSS because many webmails
strip CSS and JS. Google Mail strips embedded style tags. Different
webmails strip different things, and have different ways of formatting
the same thing (often implemented by invasive mangling of the HTML).
The result is that people revert to using table-based formatting and
*shudder* font tags *shudder* 'cos that's the only way you can get
things to even remotely resemble something sane. It's 1995 all over
again, two decades later.


T

-- 
Microsoft is to operating systems & security ... what McDonalds is to gourmet 
cooking.

Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples

[Andrei Alexandrescu]

On 9/25/12 10:05 AM, deadalnix wrote:

OK, my bad. It means that tuple(...) behave differently than T...
defined tuples.

And both behave differently than Caml or Haskell's tuples.

isn't the time for some unification ? Preferably on how tuples work in
other languages, except if limitations can be shown and better proposal
are made (and not include that in D2.xxx).


I'm not sure actually. The way I look at it, built-in tuples are quite 
low-level (types can't be spelled, automatic expansion and flattening, 
undecided first-class semantics) and should seldom be dealt with 
directly. The best use of built-in tuples is in the implementation of 
truly well-behaved, composable tuples.


Andrei

Re: std.range should support recursion (Was: One-line FFT, nice!)

[Mehrdad]

On Tuesday, 25 September 2012 at 13:34:28 UTC, Andrei 
Alexandrescu wrote:

On 9/25/12 4:23 AM, Mehrdad wrote:

On Tuesday, 25 September 2012 at 08:21:39 UTC, Mehrdad wrote:

without creating new times



new types**


Ah, better now. Still it would be great to explain it more :o).

Andrei


Haha ok. :) I mean like, essentially, these need to work:

assert(is(typeof(foo.stride(1)) == 
typeof(foo.stride(2).stride(3;

assert(is(typeof(foo.drop(1)) == typeof(foo.drop(2).drop(3;
assert(is(typeof(foo.take(1)) == typeof(foo.take(2).take(3;

otherwise recursion with these ranges is impossible.

The FFT example took the odd- and even-indexed numbers with 
stride(), but it couldn't recursively do this because the type 
system prevented it from doing so.


So I was forced to copy the array unnecessarily every time.

Also, foo should be implicitly convertible to 
typeof(foo.stride(1)), which also makes recursion easier.

Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples

[Andrej Mitrovic]

On 9/23/12, Andrei Alexandrescu  wrote:
> http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP19

Oh, I completely forgot to mention this little bug I've had due to the
comma operator a few weeks ago:

import std.stdio;

int getInt(string op)
{
if (op, "a")
return 1;
else
if (op == "b")
return 2;
else
return 3;
}

void main()
{
string op1 = "a";
string op2 = "b";
string op3 = "c";

writeln(getInt(op1));
writeln(getInt(op2));
writeln(getInt(op3));
}

It was a result of a refactoring and the bug went unnoticed until I
started getting weird results back. The if/else was much bigger and
the comma was somewhere in the middle. So yeah, nuke it from orbit!

Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples

[ixid]

You've shown it's clearly incompatible with the current language 
and would break lots of code. What would it break if assignment 
required explicit tuple brackets?


(int a, b) = foo(); // A tuple assignment, 'a' and 'b' will be 
filled in order by the multiple return values of foo()


int foo() {
return 1;
}

(int a, b) = foo(); // Also valid and only sets 'a'


int, int foo() {
return 1, 2;
}

int a = foo(); // Also valid and 'a' takes the first tuple value

(int a, auto b) = foo(); // Evaluated left to right so 'a' will 
take the first argument of foo and b will auto to a type or tuple 
of what remains. It will error if there is nothing remaining for 
b. This would still allow the clean expression of stand-alone 
tuples and function arguments and return values.


int, string a = 1, "hello";
int, string foo(double, double a) {
   return cast(int) (d[0] * d[1]), "hello";
}

Doesn't the needs of bracketing to determine order operation, 
(stuff) more or less imply that implicit conversion between one 
member tuples and the type of that tuple member is a requirement? 
Or would the (stuff, ) syntax be better?

Re: std.range should support recursion (Was: One-line FFT, nice!)

[monarch_dodra]

On Tuesday, 25 September 2012 at 15:41:42 UTC, Mehrdad wrote:
On Tuesday, 25 September 2012 at 13:34:28 UTC, Andrei 
Alexandrescu wrote:

On 9/25/12 4:23 AM, Mehrdad wrote:

On Tuesday, 25 September 2012 at 08:21:39 UTC, Mehrdad wrote:

without creating new times



new types**


Ah, better now. Still it would be great to explain it more :o).

Andrei


Haha ok. :) I mean like, essentially, these need to work:

assert(is(typeof(foo.stride(1)) == 
typeof(foo.stride(2).stride(3;

assert(is(typeof(foo.drop(1)) == typeof(foo.drop(2).drop(3;
assert(is(typeof(foo.take(1)) == typeof(foo.take(2).take(3;


I can't comment on the rest of your points, but stride and take 
DO check for type recursivity, and drop always returns the same 
type as input anyways. Failure of ANY of these asserts is a bug. 
What where your inputs?


//---
import std.range;

struct S
{
  enum empty = false;
  void popFront(){};
  @property int front(){return 1;}
}

void main()
{
  S foo;
  static assert(is(typeof(foo.stride(1)) == 
typeof(foo.stride(2).stride(3;
  static assert(is(typeof(foo.drop(1)) == 
typeof(foo.drop(2).drop(3;

  static assert(is(typeof(foo) == typeof(foo.drop(2; //Or this
  static assert(is(typeof(foo.take(1)) == 
typeof(foo.take(2).take(3;

}
//---

Re: Function prototype + definition in the same file

[Jacob Carlborg]

On 2012-09-25 13:53, Manu wrote:


I really don't like doing it this way for a number of reasons:
   *** This results in hundreds of mixins, which quickly lead to
intolerable compile times (to the point where D is losing it's appeal as
a viable choice for our needs). If done my preferred way, I could do the
magic with a single mixin at the bottom of the file.


I guess you already figured this out but a single mixin with a lot of 
code is a lot faster than several mixins with little code. Although this 
will decrease the readability even further.


--
/Jacob Carlborg

Re: Reference semantic ranges and algorithms (and std.random)

[Joseph Rushton Wakeling]

On 18/09/12 17:05, monarch_dodra wrote:

As you can see from the ouput, that is not very random. That's just the "tip of
the iceberg". *Anything* in phobos that iterates on a range, such a fill,
filter, or whatever, will not advance the PRNG, arguably breaking it.

At best, a "global" PRNG will work, provided it is never ever passed as an
argument to a method.


Just to note, we already have an existing problem with this in Phobos, with the 
RandomSample functionality.  See:

http://d.puremagic.com/issues/show_bug.cgi?id=8247

Re: C# wish list

[Paulo Pinto]

On Tuesday, 25 September 2012 at 02:15:59 UTC, bearophile wrote:

Seen on Reddit: the wish list for C#:

http://visualstudio.uservoice.com/forums/121579-visual-studio/category/30931-languages-c-

The wish #2 is to catch multiple exceptions:

try
{
// smth}
catch (RemoteException, NamingException , CreateException e)
{
// smth
}


The wish #15 for C# is nonnullable references, also discussed 
here:

http://www.reddit.com/r/programming/comments/10eq96/nonnullable_types_vs_c_fixing_the_billion_dollar/

http://twistedoakstudios.com/blog/?p=330



The wish list for F#:
http://visualstudio.uservoice.com/forums/121579-visual-studio/category/30935-languages-f-

The #10 F# wish F# wish is for "Parameterized Modules":
open Module1(p = 100)

Bye,
bearophile



Thanks for the heads up. Time to give some votes out of my MSDN 
account.


The #10 F# wish is kind of strange, after all the language 
already supports generics. I wonder which use cases it would be 
good for.


--
Paulo

Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples

[Michel Fortin]

On 2012-09-25 15:08:25 +, Andrei Alexandrescu 
 said:



On 9/25/12 10:05 AM, deadalnix wrote:

OK, my bad. It means that tuple(...) behave differently than T...
defined tuples.

And both behave differently than Caml or Haskell's tuples.

isn't the time for some unification ? Preferably on how tuples work in
other languages, except if limitations can be shown and better proposal
are made (and not include that in D2.xxx).


I'm not sure actually. The way I look at it, built-in tuples are quite 
low-level (types can't be spelled, automatic expansion and flattening, 
undecided first-class semantics) and should seldom be dealt with 
directly. The best use of built-in tuples is in the implementation of 
truly well-behaved, composable tuples.


The built-in tuple is also quite useful when defining templates.

In essence, we have two kinds of tuples: the built-in language tuple is 
the "unpacked" tuple while Phobos hosts the "packed" one. They each 
have their own use case and they can coexist peacefully. But the 
language itself needs to standardize on one or the other. Take this 
example (which is currently illegal because you can't return a built-in 
language tuple):


T getThings(T...)(T t)
{
return t;
}

In this situation, there is no question that the language tuple needs 
to work as an expanded tuple inside the parameter list of getTuple.


But now, what is the return type of makeTuple(1,2)? Obviously it's 
(int, int), but is (int, int) the same thing as T? Or is it a packed 
version of T? Well, it can't be a packed version of T because T is 
already the unpacked type. I mean that for a function that simply 
return its argument this should work:


T t1;
T t2 = getThings!(T)(t1);

If the language made T… a packed tuple instead, then we could use the 
packed tuple everywhere and unpack it where necessary, and something 
like this could be used to make a packed tuple:


T getThings(T...)(T.expand t)
{
return T(t);
}

T t1;
T t2 = getThings!(T)(t1.expand);

But we can't have it both ways, and the above would be a very drastic 
change to the language.


I'm of the opinion that if we want to add tuple returns to the language 
(which I'd certainly like), it'll have to be the same kind of tuple we 
currently have built-in in the language: the auto-expanding kind.


As we all know, this doesn't preclude anyone from building packed 
library tuples:


Tuple!(T) getThings(T...)(T t)
{
return tuple(t);
}

Although to make things less confusing, I think the built-in language 
tuple should give up its name. It could become a "sequence". Renaming 
the built-in one would certainly be less trouble, as code doesn't refer 
to it by its name, and you can pick a name that fits better with its 
auto-expanding behaviour.



--
Michel Fortin
michel.for...@michelf.ca
http://michelf.ca/

Re: std.range should support recursion (Was: One-line FFT, nice!)

[Andrei Alexandrescu]

On 9/25/12 11:42 AM, Mehrdad wrote:

On Tuesday, 25 September 2012 at 13:34:28 UTC, Andrei Alexandrescu wrote:

On 9/25/12 4:23 AM, Mehrdad wrote:

On Tuesday, 25 September 2012 at 08:21:39 UTC, Mehrdad wrote:

without creating new times



new types**


Ah, better now. Still it would be great to explain it more :o).

Andrei


Haha ok. :) I mean like, essentially, these need to work:

assert(is(typeof(foo.stride(1)) == typeof(foo.stride(2).stride(3;
assert(is(typeof(foo.drop(1)) == typeof(foo.drop(2).drop(3;
assert(is(typeof(foo.take(1)) == typeof(foo.take(2).take(3;

otherwise recursion with these ranges is impossible.


I think all of the above are doable and useful. Please file a bug report 
containing these and any others you could reasonably think of.


Thanks!

Andrei

Re: Reference semantic ranges and algorithms (and std.random)

[monarch_dodra]

On Tuesday, 25 September 2012 at 16:15:24 UTC, Joseph Rushton 
Wakeling wrote:

On 18/09/12 17:05, monarch_dodra wrote:
As you can see from the ouput, that is not very random. That's 
just the "tip of
the iceberg". *Anything* in phobos that iterates on a range, 
such a fill,
filter, or whatever, will not advance the PRNG, arguably 
breaking it.


At best, a "global" PRNG will work, provided it is never ever 
passed as an

argument to a method.


Just to note, we already have an existing problem with this in 
Phobos, with the RandomSample functionality.  See:

http://d.puremagic.com/issues/show_bug.cgi?id=8247


Thank you for bringing it up. The problem is indeed as you said, 
and making the PRNGs references types fixes it.


I have a pretty well developed first iteration. I hope that by 
the end of next week, I'll have something to show.


Right now, I'm at a crossroad between:
*Inserting (requested) new features, (forced stack allocation, 
pre-initialized ranges for performance)
*Strictly no new features, for an eventual (easier) breaking 
change.


The problem with inserting "workaround 'features'", is that you 
have to keep supporting even if it is not required anymore :p

Re: std.range should support recursion (Was: One-line FFT, nice!)

[Mehrdad]

On Tuesday, 25 September 2012 at 16:03:22 UTC, monarch_dodra 
wrote:

On Tuesday, 25 September 2012 at 15:41:42 UTC, Mehrdad wrote:
On Tuesday, 25 September 2012 at 13:34:28 UTC, Andrei 
Alexandrescu wrote:

On 9/25/12 4:23 AM, Mehrdad wrote:

On Tuesday, 25 September 2012 at 08:21:39 UTC, Mehrdad wrote:

without creating new times



new types**


Ah, better now. Still it would be great to explain it more 
:o).


Andrei


Haha ok. :) I mean like, essentially, these need to work:

assert(is(typeof(foo.stride(1)) == 
typeof(foo.stride(2).stride(3;

assert(is(typeof(foo.drop(1)) == typeof(foo.drop(2).drop(3;
assert(is(typeof(foo.take(1)) == typeof(foo.take(2).take(3;


I can't comment on the rest of your points, but stride and take 
DO check for type recursivity, and drop always returns the same 
type as input anyways. Failure of ANY of these asserts is a 
bug. What where your inputs?



I just wrote down the assert's on the fly, actually.
Maybe I'm just misinterpreting the error then, and the problem is 
somewhere else?

The code I was trying to compile is this (sorry it's ugly):

import std.algorithm, std.math, std.range;
typeof(R.init.stride(0)) dft(R)(R v)
{
return v.length <= 1
? v.stride(1)
: (p =>
   chain(map!(q => q[0] + q[1])(p),
 map!(q => q[0] - q[1])(p)))
  (zip(dft(v.stride(2)),
map!(p => p[1] * expi(p[0] * -2 * PI / v.length))
(zip(iota(v.length / 2),
 dft(v.drop(1).stride(2));
}
void main() { dft([1.0, 2, 3]); }


Which gives the following error:


Test.d(5): Error: incompatible types for ((stride(v,1u)) ? 
((*delegate @system 
Result(Zip!(Result,MapResult!(__lambda8,Zip!(Result,Result))) p)

{
return chain(map(p),map(p));
}
)(zip(dft(stride(v,2u)),map(zip(iota(v.length() / 
2u),dft(stride(drop(v,1u),2u: 'Result' and 'Result'
Test.d(10): Error: template instance Test.dft!(Result) error 
instantiating

Test.d:19: instantiated from here: dft!(double[])
Test.d(5): Error: incompatible types for ((stride(v,1u)) ? 
((*delegate @system 
Result(Zip!(Result,MapResult!(__lambda8,Zip!(Result,Result))) p)

{
return chain(map(p),map(p));
}
)(zip(dft(stride(v,2u)),map(zip(iota(v.length / 
2u),dft(stride(drop(v,1u),2u: 'Result' and 'Result'
Test.d(19): Error: template instance Test.dft!(double[]) error 
instantiating




How should I interpret it?

Thanks!

Re: std.range should support recursion (Was: One-line FFT, nice!)

[Mehrdad]

On Tuesday, 25 September 2012 at 16:31:15 UTC, Andrei 
Alexandrescu wrote:
I think all of the above are doable and useful. Please file a 
bug report containing these and any others you could reasonably 
think of.


Thanks!

Andrei


Sure! I'll file them as soon as I know they're bugs -- 
monarch_dodra's comment makes me think it might just be my 
misinterpretation of the error.

Re: Function prototype + definition in the same file

[Steven Schveighoffer]

On Tue, 25 Sep 2012 10:40:41 -0400, Manu  wrote:

On 25 September 2012 17:25, Steven Schveighoffer  
wrote:



On Tue, 25 Sep 2012 07:53:17 -0400, Manu  wrote:

 So I have this recurring pattern, it's really starting to annoy me.

It stems from the fact that a function prototype and the definition can
not
appear in the same file in D (as it can in C/C++)



Doing this is not illegal.


 Eg,


void func(int x); // <-- declaration of function, informs type and
associated names, args, ...

//later
void func(int x) // <-- may be generated with magic (and may use the
prototype declaration for type information as declared by the prototype
above)
{
  ... do stuff
}



This compiles.  Do you have a better case to show the problem?



void blah();

void  blah()
{
int x = 0;
}

void f()
{
   blah(); // <- call it
}


W:\project\main\sourcedata\plugins\remedy\modules\test_module.d(38):Error:
function remedy.testmodule.blah called with argument types:
(())
matches both:
remedy.testmodule.blah()
and:
remedy.testmodule.blah()


Oh, that is funny.  I simply compiled the functions and didn't call them,  
assuming if that compiled it was legal.


This is definitely a bug.  In fact you can implement a function *twice*  
and this isn't an error.


Check this out:

testme2.d:

module testme2;
import std.stdio;

void foo()
{
writeln("first");
}

void foo()
{
writeln("second");
}

testme2.di:

module testme2;

void foo();

testme.d:
import testme2;

void main()
{
foo();
}

Compile like this:

dmd -c testme2.d
dmd testme.d testme2.o

links, and when I run, it displays:

first

So clearly there isn't something right here, that should definitely be an  
error.


I think there are two errors here.  First, the spec does not say you  
cannot prototype a function before declaring it.  All it says is:


Functions without bodies:

int foo();

that are not declared as abstract are expected to have their  
implementations elsewhere, and that implementation will be provided at the  
link step. This enables an implementation of a function to be completely  
hidden from the user of it, and the implementation may be in another  
language such as C, assembler, etc.


from: http://dlang.org/function.html

I don't see any rules that would preclude pre-declaring a prototype, even  
if it's not promoted to do this (after all, forward references should  
always work, right?).


Second, you should not be able to compile two identically prototyped  
functions with bodies into an object file,  I have no idea how that even  
works.


-Steve

Re: Function prototype + definition in the same file

[Jonathan M Davis]

On Tuesday, September 25, 2012 14:53:17 Manu wrote:
> I really need this. Why is it illegal? Is there chance of having this
> supported? What are the problems?

I confess that I don't understand why you'd ever need function prototypes, so 
clearly one (or both) of us is missing something here.

If you you've defined the function, it's there, and that should provide dynamic 
linkage just fine. The only cases that I can think of where the function 
_wouldn't_ be defined in spite of actually be in the source file are when it's 
in a version block or static if which isn't compiled in (in which case, it's 
not _supposed_ to exist) or if it's a template, in which case, AFAIK, it's 
_never_ dynamically linkable, but rather it's instantiated in the code which 
uses the library when it uses that templated function.

So, what am I missing here?

- Jonathan M Davis

Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples

[Jonathan M Davis]

On Tuesday, September 25, 2012 12:28:15 Michel Fortin wrote:
> Although to make things less confusing, I think the built-in language
> tuple should give up its name. It could become a "sequence". Renaming
> the built-in one would certainly be less trouble, as code doesn't refer
> to it by its name, and you can pick a name that fits better with its
> auto-expanding behaviour.

Not referred to by its name? It's refereed to as TypeTuple all over the place. 
It's arguably a bad name, but it would break a _lot_ of code to change it now.

- Jonathan M Davis

Is flags enum needed in Phobos?

[Denis Shelomovskij]

.NET has FlagsAttribute, Java has EnumSet. Looks like we need this too. 
How about to add a library solution to Phobos?


My variant is here (search for `flagEnum`):
https://bitbucket.org/denis_sh/misc/src/tip/stdd/typecons.d

It has a bug and I have no idea how to fix it:
`AB.init |= AB.a` and `AB.a |= AB.a` are allowed.
(no, we can't make `AB.a` const to disallow the second case because it 
will disallow this: `auto a = AB.a; a |= AB.a;`)


Also I'm not sure:
* Should we support converting from a number to a flag enum?
* If so, should we support values not from enum flags or throw 
exceptions (it may be configurable)?

* Is `flagEnum` an appropriate name?



--
Денис В. Шеломовский
Denis V. Shelomovskij

Re: [OT] Was: totally satisfied :D

[Sean Kelly]

On Sep 24, 2012, at 6:55 PM, Nick Sabalausky 
 wrote:

> On Mon, 24 Sep 2012 18:10:09 -0700
> "H. S. Teoh"  wrote:
> 
>> On Mon, Sep 24, 2012 at 07:52:15PM -0400, Nick Sabalausky wrote:
>> 
>>> A lot of the videogames I've played have independent adjustable
>>> SFX/music/voice volumes. I've even happily made use of that. And I'm
>>> damn glad that the TV *still* has a properly working volume control
>>> despite that because I make even more use of that.
>> 
>> Yeah I almost never play games with music on, 'cos I generally find
>> the music not to my liking. SFX I sometimes leave on low, though on
>> handhelds I generally turn both off. But the option to only have SFX
>> without music is a plus. I *have* deleted apps before that didn't
>> allow independent settings.
>> 
> 
> I never used to mute videogame music until they started licensing stuff
> from the record labels. Like all that "EA Trax" stuff. Blech. Last
> generation, that was one of the great things about the XBox: custom
> soundtracks. My brother introduced me to Quarashi's Jinx album which
> made for a far better soundtrack for THPS2X than the built-in songs.
> The Tony Hawk games from 3 onward were almost unplayable with the
> built-in music enabled.

One really interesting side effect of using licensed music in games is that it 
can prevent the game from being re-released as a "classic" later on, ported to 
other platforms, etc, if the licensing deal didn't include a clause for that 
(which is typically the case). There have been games re-released in the past 
few years with no music track because the license didn't allow for its 
inclusion. 

Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples

[Michel Fortin]

On 2012-09-25 16:38:31 +, "Jonathan M Davis"  said:


On Tuesday, September 25, 2012 12:28:15 Michel Fortin wrote:

Although to make things less confusing, I think the built-in language
tuple should give up its name. It could become a "sequence". Renaming
the built-in one would certainly be less trouble, as code doesn't refer
to it by its name, and you can pick a name that fits better with its
auto-expanding behaviour.


Not referred to by its name? It's refereed to as TypeTuple all over the place.
It's arguably a bad name, but it would break a _lot_ of code to change it now.


TypeTuple is only a construct allowing you to create a built-in 
language tuple, one that does not necessarily match the definition of a 
TypeTuple. The language spec defines a Tuples, TypeTuples, and 
ExpressionTuples with these words (ironically, using the word 
"sequence" twice):


"""
If the last template parameter in the TemplateParameterList is declared 
as a TemplateTupleParameter, it is a match with any trailing template 
arguments. The sequence of arguments form a Tuple. A Tuple is not a 
type, an expression, or a symbol. It is a sequence of any mix of types, 
expressions or symbols.


A Tuple whose elements consist entirely of types is called a TypeTuple. 
A Tuple whose elements consist entirely of expressions is called an 
ExpressionTuple.

"""
Source: http://dlang.org/template.html

--
Michel Fortin
michel.for...@michelf.ca
http://michelf.ca/

Re: std.range should support recursion (Was: One-line FFT, nice!)

[jerro]

import std.algorithm, std.math, std.range;
typeof(R.init.stride(0)) dft(R)(R v)
{
return v.length <= 1
? v.stride(1)
: (p =>
   chain(map!(q => q[0] + q[1])(p),
 map!(q => q[0] - q[1])(p)))
  (zip(dft(v.stride(2)),
map!(p => p[1] * expi(p[0] * -2 * PI / v.length))
(zip(iota(v.length / 2),
 dft(v.drop(1).stride(2));
}
void main() { dft([1.0, 2, 3]); }


Which gives the following error:


Test.d(5): Error: incompatible types for ((stride(v,1u)) ? 
((*delegate @system 
Result(Zip!(Result,MapResult!(__lambda8,Zip!(Result,Result))) p)

{
return chain(map(p),map(p));
}
)(zip(dft(stride(v,2u)),map(zip(iota(v.length() / 
2u),dft(stride(drop(v,1u),2u: 'Result' and 'Result'
Test.d(10): Error: template instance Test.dft!(Result) error 
instantiating

Test.d:19: instantiated from here: dft!(double[])
Test.d(5): Error: incompatible types for ((stride(v,1u)) ? 
((*delegate @system 
Result(Zip!(Result,MapResult!(__lambda8,Zip!(Result,Result))) p)

{
return chain(map(p),map(p));
}
)(zip(dft(stride(v,2u)),map(zip(iota(v.length / 
2u),dft(stride(drop(v,1u),2u: 'Result' and 'Result'
Test.d(19): Error: template instance Test.dft!(double[]) error 
instantiating




How should I interpret it?

Thanks!


One possible reason for this error could be that you are 
returning a result of chain() if length is larger than 1 and a 
result of stride() otherwise.

Re: Function prototype + definition in the same file

[deadalnix]

Le 25/09/2012 13:53, Manu a écrit :

So I have this recurring pattern, it's really starting to annoy me.
It stems from the fact that a function prototype and the definition can
not appear in the same file in D (as it can in C/C++)
Eg,

void func(int x); // <-- declaration of function, informs type and
associated names, args, ...

//later
void func(int x) // <-- may be generated with magic (and may use the
prototype declaration for type information as declared by the prototype
above)
{
   ... do stuff
}

I really need this. Why is it illegal? Is there chance of having this
supported? What are the problems?

My problem is essentially to do with supporting both static or dynamic
linkage optionally, but it also shows up in situations where I want to
perform comprehensive magic code generation, but want clear-readable
user declarations.
The simplest case:
   I have an extern that I may want to statically or dynamically link.
 In the case of static linkage, one just produces a prototype, and
it links, no problem.
 In the case of dynamic linkage, one must produce a stub for the
function, a function pointer to call through, and perhaps some code to
hook-up the function pointer at init.

I have a fairly comprehensive binding solution which automates the work
in the case of dynamic linkage, but the problem is the way the user
defines the functions that exist in the D code.
I'd like it if the users would just write the prototypes, they'd be
easily readable, simple to create by cutting and pasting straight from C
code. And when statically linking, it would just work, the module
hook-up mixin does nothing in this configuration.
In the case of dynamic linkage, a single hook-up mixin in the file
somewhere could scan the module for these prototypes and generate the
stubs, function pointers, and the boot-up code that would connect them
(while validating their signatures against the extern import table, etc).

This approach isn't supported though. What I do instead:

mixin( ImportFunction!( "functionName", int function( int arg1, float
arg2, ref in SomeStruct arg3 ), "pure nothrow" ) );
mixin( ImportFunction!( "functionName2", int function() ) );
mixin( ImportFunction!( "functionName3", int function( int x, int y ),
"nothrow" ) );
etc etc

These templates produce, from the information provided, either a
prototype for static linkage, or the { stub, func pointer,
initialisation info } for dynamic linkage.

I really don't like doing it this way for a number of reasons:
   *** This results in hundreds of mixins, which quickly lead to
intolerable compile times (to the point where D is losing it's appeal as
a viable choice for our needs). If done my preferred way, I could do the
magic with a single mixin at the bottom of the file.
   * It's barely readable.
   * Much more annoying to write and maintain when the counterpart API
changes, and is more error-prone.
   * IDE features don't work properly; syntax highlighting, hover info,
go-to-definition, etc.

I also have numerous more advanced cases of the same problem, and
becomes even more unsightly when used in structs to emulate dynamic
linkage to static methods of C++ classes.

The solution is seemingly trivial; allow function prototypes and
definitions to exist in the same file, like in C/C++.


Go on, tear me apart... :)


This is code duplication and is generally considered as a bad practice. 
I'm not convinced that the language should be modified to allow 
something that is known as bad practice.


What you need here is a more robust di generator IMO.

Re: Function prototype + definition in the same file

[deadalnix]

Le 25/09/2012 18:38, Jonathan M Davis a écrit :

On Tuesday, September 25, 2012 14:53:17 Manu wrote:

I really need this. Why is it illegal? Is there chance of having this
supported? What are the problems?


I confess that I don't understand why you'd ever need function prototypes, so
clearly one (or both) of us is missing something here.



It can help IDE for instance. Or help the programmer when looking for 
references in the source code.

implicit conversion from bool to char, is it really necessary ?

[deadalnix]

Today, I spent quite a lot of time because a stupid problem. It 
basically boil down to :


bool b; // Defined elsewhere.
string s = "somestring" ~ b?"":"somemorestring";

Obviously, I intended to write
string s = "somestring" ~ (b?"":"somemorestring");

but, due to operator priority, it is means
string s = ("somestring" ~ b)?"":"somemorestring";

So what ? So it compile without even a warning. I missed the error 
because I expected to get a type error in such case. So I assumed that 
the code was correct.


After checking in TDPL, it is stated that ubyte and char should 
implicitly cast to one another. And as bool implicitly convert to ubyte, 
this is effectively the specified behavior.


I think this is a rather problematic behavior. What is the point of have 
both byte and char types if both are implicitly convertible to one 
another (and have completely different semantic) ?

Re: Is flags enum needed in Phobos?

[bearophile]

On Tuesday, 25 September 2012 at 17:13:44 UTC, Denis Shelomovskij 
wrote:
.NET has FlagsAttribute, Java has EnumSet. Looks like we need 
this too. How about to add a library solution to Phobos?


See also:
http://d.puremagic.com/issues/show_bug.cgi?id=6946

Bye,
bearophile

Re: std.range should support recursion (Was: One-line FFT, nice!)

[jerro]

On Tuesday, 25 September 2012 at 17:48:49 UTC, jerro wrote:

import std.algorithm, std.math, std.range;
typeof(R.init.stride(0)) dft(R)(R v)
{
return v.length <= 1
? v.stride(1)
: (p =>
   chain(map!(q => q[0] + q[1])(p),
 map!(q => q[0] - q[1])(p)))
  (zip(dft(v.stride(2)),
map!(p => p[1] * expi(p[0] * -2 * PI / v.length))
(zip(iota(v.length / 2),
 dft(v.drop(1).stride(2));
}
void main() { dft([1.0, 2, 3]); }


Which gives the following error:


Test.d(5): Error: incompatible types for ((stride(v,1u)) ? 
((*delegate @system 
Result(Zip!(Result,MapResult!(__lambda8,Zip!(Result,Result))) 
p)

{
return chain(map(p),map(p));
}
)(zip(dft(stride(v,2u)),map(zip(iota(v.length() / 
2u),dft(stride(drop(v,1u),2u: 'Result' and 'Result'
Test.d(10): Error: template instance Test.dft!(Result) error 
instantiating

Test.d:19: instantiated from here: dft!(double[])
Test.d(5): Error: incompatible types for ((stride(v,1u)) ? 
((*delegate @system 
Result(Zip!(Result,MapResult!(__lambda8,Zip!(Result,Result))) 
p)

{
return chain(map(p),map(p));
}
)(zip(dft(stride(v,2u)),map(zip(iota(v.length / 
2u),dft(stride(drop(v,1u),2u: 'Result' and 'Result'
Test.d(19): Error: template instance Test.dft!(double[]) error 
instantiating




How should I interpret it?

Thanks!


One possible reason for this error could be that you are 
returning a result of chain() if length is larger than 1 and a 
result of stride() otherwise.


I'd like to add that I don't think you can make this work the way 
you meant it to. The problem is that you return a chain when the 
length is 2, a chain of chains when the length is 4, and so on. 
What fft of length n would actually need to return is a binary 
tree of ranges with n leaves. The size of memory needed for the 
value returned from fft therefore depends on the length of the 
range it was given as an argument. So you need to either use heap 
allocated memory for the return type, or the return type needs to 
depend on the parameter range's length, which would mean that the 
parameter range's length needs to be a template parameter.


I think there is one thing in this code that will hurt 
performance much, much, more than allocations. This code will 
compute elements of the result lazily. So each time you want to 
read an element from the resulting range, O(log(n)) functions 
passed to map() will need to be computed. The problem is that 
each of those functions computes sine and cosine, so sine and 
cosine need to be computed O(log(n)) times for each element. To 
get all n elements, you will need to compute them O(n log(n)). 
Because computing sine and cosine is about two orders of 
magnitude slower than multiplication and division, this will be 
very slow.

Re: Function prototype + definition in the same file

[Jonathan M Davis]

On Tuesday, September 25, 2012 19:51:42 deadalnix wrote:
> Le 25/09/2012 18:38, Jonathan M Davis a écrit :
> > On Tuesday, September 25, 2012 14:53:17 Manu wrote:
> >> I really need this. Why is it illegal? Is there chance of having this
> >> supported? What are the problems?
> > 
> > I confess that I don't understand why you'd ever need function prototypes,
> > so clearly one (or both) of us is missing something here.
> 
> It can help IDE for instance. Or help the programmer when looking for
> references in the source code.

I don't understand this. The IDE can see what functions are there. How would 
having a function prototype affect that? It has to look for the real function 
regardless, since there's no guarantee that they all have prototypes. The same 
goes for the programmer. And if it's a matter of knowing what functions in a 
module are publicly available to use, then that's what generated documentation 
is for. The only languages that I know of which use prototypes are C and C++, 
and folks in other languages get by just fine without them. They only exist in 
C/C++ beacuse of its antiquated compilation model. Sure, they could be useful 
at times for documentation purposes, but it's code duplication which may or 
may not be up-to-date with the actual code, especially when the language is 
advanced enough that it doesn't need a function to be declared earlier in the 
file than where it's called. And generated documentation or an IDE solves the 
problem of getting a list of the functions if that's what you want.

Regardless, Manu seems to have issues related to linking, which is a 
completely separate issue and that's what I don't understand.

- Jonathan M Davis

Re: std.range should support recursion (Was: One-line FFT, nice!)

[jerro]

I think there is one thing in this code that will hurt 
performance much, much, more than allocations. This code will 
compute elements of the result lazily. So each time you want to 
read an element from the resulting range, O(log(n)) functions 
passed to map() will need to be computed. The problem is that 
each of those functions computes sine and cosine, so sine and 
cosine need to be computed O(log(n)) times for each element. To 
get all n elements, you will need to compute them O(n log(n)). 
Because computing sine and cosine is about two orders of 
magnitude slower than multiplication and division, this will be 
very slow.


I was wrong about the complexity. Because each element of the 
result depends on all the elements of the argument range, you 
actually need O(n) function calls to compute each element of the 
result and O(n*n) function calls(and sine and cosine 
computations) to compute all of them. You would need to use 
memoization to get reasonable complexity.

Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples

[Jonathan M Davis]

On Tuesday, September 25, 2012 13:45:50 Michel Fortin wrote:
> On 2012-09-25 16:38:31 +, "Jonathan M Davis"  said:
> > On Tuesday, September 25, 2012 12:28:15 Michel Fortin wrote:
> >> Although to make things less confusing, I think the built-in language
> >> tuple should give up its name. It could become a "sequence". Renaming
> >> the built-in one would certainly be less trouble, as code doesn't refer
> >> to it by its name, and you can pick a name that fits better with its
> >> auto-expanding behaviour.
> > 
> > Not referred to by its name? It's refereed to as TypeTuple all over the
> > place. It's arguably a bad name, but it would break a _lot_ of code to
> > change it now.
> TypeTuple is only a construct allowing you to create a built-in
> language tuple, one that does not necessarily match the definition of a
> TypeTuple. The language spec defines a Tuples, TypeTuples, and
> ExpressionTuples with these words (ironically, using the word
> "sequence" twice):
> 
> """
> If the last template parameter in the TemplateParameterList is declared
> as a TemplateTupleParameter, it is a match with any trailing template
> arguments. The sequence of arguments form a Tuple. A Tuple is not a
> type, an expression, or a symbol. It is a sequence of any mix of types,
> expressions or symbols.
> 
> A Tuple whose elements consist entirely of types is called a TypeTuple.
> A Tuple whose elements consist entirely of expressions is called an
> ExpressionTuple.
> """
> Source: http://dlang.org/template.html

I wasn't aware of that being in the language definition, but it doesn't change 
the fact that they're used and referred to in code as TypeTuple, and renaming 
that would break a lot of code. And it _is_ used for the built-in tuple type, 
regardless of whether the spec considers the terms type tuple and expression 
tuple to refer to distinct entities. Rename the stuff in the spec to whatever 
you like, but the library uses the term TypeTuple, so it _is_ used in code.

- Jonathan M Davis

Re: Function prototype + definition in the same file

[Maxim Fomin]

On Tuesday, 25 September 2012 at 17:48:46 UTC, deadalnix wrote:
This is code duplication and is generally considered as a bad 
practice. I'm not convinced that the language should be 
modified to allow something that is known as bad practice.


What you need here is a more robust di generator IMO.


This is neither a code duplication (there is certain distinction 
between prototype and body) nor a bad practice - this is a common 
pattern in C and C++. It is surprising that D cannot do such a 
simple thing which in addition is not harmless, so there is no 
sense in depreciating it.

Re: Function prototype + definition in the same file

[deadalnix]

Le 25/09/2012 20:57, Maxim Fomin a écrit :

On Tuesday, 25 September 2012 at 17:48:46 UTC, deadalnix wrote:

This is code duplication and is generally considered as a bad
practice. I'm not convinced that the language should be modified to
allow something that is known as bad practice.

What you need here is a more robust di generator IMO.


This is neither a code duplication (there is certain distinction between
prototype and body) nor a bad practice - this is a common pattern in C
and C++. It is surprising that D cannot do such a simple thing which in
addition is not harmless, so there is no sense in depreciating it.


This is code duplication. And this has been considered a problem in 
C/C++ for a while now.

Re: Function prototype + definition in the same file

[deadalnix]

Le 25/09/2012 20:05, Jonathan M Davis a écrit :

On Tuesday, September 25, 2012 19:51:42 deadalnix wrote:

Le 25/09/2012 18:38, Jonathan M Davis a écrit :

On Tuesday, September 25, 2012 14:53:17 Manu wrote:

I really need this. Why is it illegal? Is there chance of having this
supported? What are the problems?


I confess that I don't understand why you'd ever need function prototypes,
so clearly one (or both) of us is missing something here.


It can help IDE for instance. Or help the programmer when looking for
references in the source code.


I don't understand this. The IDE can see what functions are there. How would
having a function prototype affect that? It has to look for the real function
regardless, since there's no guarantee that they all have prototypes. The same
goes for the programmer. And if it's a matter of knowing what functions in a
module are publicly available to use, then that's what generated documentation
is for. The only languages that I know of which use prototypes are C and C++,
and folks in other languages get by just fine without them. They only exist in
C/C++ beacuse of its antiquated compilation model. Sure, they could be useful
at times for documentation purposes, but it's code duplication which may or
may not be up-to-date with the actual code, especially when the language is
advanced enough that it doesn't need a function to be declared earlier in the
file than where it's called. And generated documentation or an IDE solves the
problem of getting a list of the functions if that's what you want.

Regardless, Manu seems to have issues related to linking, which is a
completely separate issue and that's what I don't understand.

- Jonathan M Davis


I'm playing devil advocate here, I answered elsewhere that I would be 
against such modification of the language.

Re: implicit conversion from bool to char, is it really necessary ?

[bearophile]

deadalnix:


bool b; // Defined elsewhere.
string s = "somestring" ~ b?"":"somemorestring";


bool => char implicit conversion is not commonly useful in 
programs, but I think it's also not a common bug.


On the other hand in past we have discussed a little about the 
bug-prone precedence of the ?: operator. Analysis of shared code 
repositories shows that this is a common source of bugs. So I 
think avoiding this bug has higher priority (and it's enough to 
avoid your specific bug).


One of the ideas for D was that when the ?: is included in a 
larger expression, to requires parentheses around it.


auto x1 = y1 ? z1 : w1; // OK
auto x2 = x0 + (y1 ? z1 : w1); // OK
auto x3 = (x0 + y1) ? z1 : w1); // OK
auto x4 = x0 + y1 ? z1 : w1; // error
auto x5 = y1 ? z1 : (y2 ? z2 : w2); // OK
auto x6 = y1 ? z1 : y2 ? z2 : w2; // error

In theory this increases the number of parentheses a little, but 
in practice in many similar situations I already put those 
parentheses, for readability and to avoid some of my mistakes.


Bye,
bearophile

Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples

[kenji hara]

2012/9/26 Jonathan M Davis :
> On Tuesday, September 25, 2012 13:45:50 Michel Fortin wrote:
>> On 2012-09-25 16:38:31 +, "Jonathan M Davis"  said:
>> > On Tuesday, September 25, 2012 12:28:15 Michel Fortin wrote:
>> >> Although to make things less confusing, I think the built-in language
>> >> tuple should give up its name. It could become a "sequence". Renaming
>> >> the built-in one would certainly be less trouble, as code doesn't refer
>> >> to it by its name, and you can pick a name that fits better with its
>> >> auto-expanding behaviour.
>> >
>> > Not referred to by its name? It's refereed to as TypeTuple all over the
>> > place. It's arguably a bad name, but it would break a _lot_ of code to
>> > change it now.
>> TypeTuple is only a construct allowing you to create a built-in
>> language tuple, one that does not necessarily match the definition of a
>> TypeTuple. The language spec defines a Tuples, TypeTuples, and
>> ExpressionTuples with these words (ironically, using the word
>> "sequence" twice):
>>
>> """
>> If the last template parameter in the TemplateParameterList is declared
>> as a TemplateTupleParameter, it is a match with any trailing template
>> arguments. The sequence of arguments form a Tuple. A Tuple is not a
>> type, an expression, or a symbol. It is a sequence of any mix of types,
>> expressions or symbols.
>>
>> A Tuple whose elements consist entirely of types is called a TypeTuple.
>> A Tuple whose elements consist entirely of expressions is called an
>> ExpressionTuple.
>> """
>> Source: http://dlang.org/template.html
>
> I wasn't aware of that being in the language definition, but it doesn't change
> the fact that they're used and referred to in code as TypeTuple, and renaming
> that would break a lot of code. And it _is_ used for the built-in tuple type,
> regardless of whether the spec considers the terms type tuple and expression
> tuple to refer to distinct entities. Rename the stuff in the spec to whatever
> you like, but the library uses the term TypeTuple, so it _is_ used in code.
>
> - Jonathan M Davis

I like current design - open (built-in, automatically flattened, and
*unpacked*) tuple, and closed (library, be structured, and *packed*)
tuple.

But, the two are often confused, by the word "tuple". It has
introduced badly confusion in many discussions.
To make matters worse, it had often invoked incorrect suggestion that
merging the two into one.

My suggestion is very simple.
1. Change all words "built-in tuple" in the documentation to "built-in
sequence". Then, in the D language world, we can have clarify name for
the built-in one.
2. Introduce new templates, Seq, TypeSeq, and ExpSeq.

template Seq(T...) { alias T Seq; }// identical with
std.typetuple.TypeTuple
template TypeSeq(T...) if (allSatisfy!(isType, T)) { alias T TypeSeq; }
template ExpSeq(T...) if (allSatisfy!(isExpression, T)) { alias T ExpSeq; }

  If you really want to a sequence with heterogeneous elements, use
Seq template. Otherwise use TypeSeq or ExpSeq based on your purpose.

Kenji Hara

Re: implicit conversion from bool to char, is it really necessary ?

[bearophile]

auto x3 = (x0 + y1) ? z1 : w1); // OK


Sorry, that was:

auto x3 = (x0 + y1) ? z1 : w1; // OK

Bye,
bearophile

Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples

[David Piepgrass]

The built-in tuple is also quite useful when defining templates.

In essence, we have two kinds of tuples: the built-in language 
tuple is the "unpacked" tuple while Phobos hosts the "packed" 
one. They each have their own use case and they can coexist 
peacefully. But the language itself needs to standardize on one 
or the other.


+1, and it should standardize on "packed" (non-expanded) tuples 
because "unpacked" ones have very unusual behavior, and because 
it's impractical to eliminate "packed" tuples but practical to 
eliminate "unpacked" ones. "unpacked" tuples should only exist as 
an intermediate result (the result of .expand).


If the language made T… a packed tuple instead, then we could 
use the packed tuple everywhere and unpack it where necessary, 
and something like this could be used to make a packed tuple:


T getThings(T...)(T.expand t)
{
return T(t);
}

T t1;
T t2 = getThings!(T)(t1.expand);


"T.expand" naturally has the connotation "unpacked" to me, 
whereas what you really want to do is indicate that "t" is 
packed, right? Clearly, the syntax for a varargs template like 
this would have to change to indicate that T is non-expanded; 
unfortunately, I don't have a really compelling syntax to suggest.


P.S. If non-expanded tuples were the default, they should 
probably have a quicker syntax than "t.expand" to expand them. I 
suggest overloading unary * as in "*t"; this is known as the 
"explode" operator in boo.

Should this be flagged as a warning?

[Bernard Helyer]

I tried to post this last night, but the NG wasn't having any of 
it.


I found myself writing a bug that looked like this

match(ts, TokenType.Is);
match(ts, TokenType.OpenParen);
isExp.type == parseType(ts);

The bug being of course, that a type is parsed and ts is modified,
so the expression has side effects so it's not flagged as a 
useless
expression. But the comparison still has no effect, so should 
this be

flagged by DMD?

-Bernard.

Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples

[ixid]

"T.expand" naturally has the connotation "unpacked" to me,


Isn't T.unpack clearer? Does that clash with a different usage 
for the term?

Re: Function prototype + definition in the same file

[Steven Schveighoffer]

On Tue, 25 Sep 2012 15:23:50 -0400, deadalnix  wrote:


Le 25/09/2012 20:57, Maxim Fomin a écrit :

On Tuesday, 25 September 2012 at 17:48:46 UTC, deadalnix wrote:

This is code duplication and is generally considered as a bad
practice. I'm not convinced that the language should be modified to
allow something that is known as bad practice.

What you need here is a more robust di generator IMO.


This is neither a code duplication (there is certain distinction between
prototype and body) nor a bad practice - this is a common pattern in C
and C++. It is surprising that D cannot do such a simple thing which in
addition is not harmless, so there is no sense in depreciating it.


This is code duplication. And this has been considered a problem in  
C/C++ for a while now.


No, it's a prototype.

Note that it's *required* if you want to hide implementation using .di  
files.


There is no code involved, it's just generating a symbol reference in the  
object file.


-Steve

Re: Is flags enum needed in Phobos?

[Denis Shelomovskij]

25.09.2012 22:03, bearophile пишет:

On Tuesday, 25 September 2012 at 17:13:44 UTC, Denis Shelomovskij wrote:

.NET has FlagsAttribute, Java has EnumSet. Looks like we need this
too. How about to add a library solution to Phobos?


See also:
http://d.puremagic.com/issues/show_bug.cgi?id=6946

Bye,
bearophile


Thanks, I was almost sure there is such issue. I added to the issue a 
link to this thread.


--
Денис В. Шеломовский
Denis V. Shelomovskij

Re: Function prototype + definition in the same file

[Jonathan M Davis]

On Tuesday, September 25, 2012 15:48:11 Steven Schveighoffer wrote:
> On Tue, 25 Sep 2012 15:23:50 -0400, deadalnix  wrote:
> > Le 25/09/2012 20:57, Maxim Fomin a écrit :
> >> On Tuesday, 25 September 2012 at 17:48:46 UTC, deadalnix wrote:
> >>> This is code duplication and is generally considered as a bad
> >>> practice. I'm not convinced that the language should be modified to
> >>> allow something that is known as bad practice.
> >>> 
> >>> What you need here is a more robust di generator IMO.
> >> 
> >> This is neither a code duplication (there is certain distinction between
> >> prototype and body) nor a bad practice - this is a common pattern in C
> >> and C++. It is surprising that D cannot do such a simple thing which in
> >> addition is not harmless, so there is no sense in depreciating it.
> > 
> > This is code duplication. And this has been considered a problem in
> > C/C++ for a while now.
> 
> No, it's a prototype.
> 
> Note that it's *required* if you want to hide implementation using .di
> files.
> 
> There is no code involved, it's just generating a symbol reference in the
> object file.

It's still code duplication, because you've now listed the function signature 
twice. Yes, it's minimal code duplication, but it's still duplicating code. 
It's necessary for stuff like .di files (which are code duplication by 
definition, because they're duplicating a module - or at least part of it), but 
most everyone I know has thought (where it's come anyway) that prototypes were 
a _bad_ thing about C/C++. So, eliminating them as much as possible would 
generally be good, and even when it comes to .di files, given their limitations 
(e.g. disabling inlining and CTFE), we arguably should have a better solution 
for interface files anyway (e.g. having a binary file with the partially 
compiled code and generated documentation alongside it giving the API), in 
which case we wouldn't even need prototypes for interface files anymore. If
anything, I'd argue that the fact that prototypes are part of the language is
a sign of a deficiency in the language (especially if they're necessary).

- Jonathan M Davis

Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples

[Jonathan M Davis]

On Wednesday, September 26, 2012 04:29:13 kenji hara wrote:
> But, the two are often confused, by the word "tuple". It has
> introduced badly confusion in many discussions.
> To make matters worse, it had often invoked incorrect suggestion that
> merging the two into one.
> 
> My suggestion is very simple.
> 1. Change all words "built-in tuple" in the documentation to "built-in
> sequence". Then, in the D language world, we can have clarify name for
> the built-in one.
> 2. Introduce new templates, Seq, TypeSeq, and ExpSeq.
> 
> template Seq(T...) { alias T Seq; } // identical with
> std.typetuple.TypeTuple
> template TypeSeq(T...) if (allSatisfy!(isType, T)) { alias T TypeSeq; }
> template ExpSeq(T...) if (allSatisfy!(isExpression, T)) { alias T
> ExpSeq; }
> 
> If you really want to a sequence with heterogeneous elements, use
> Seq template. Otherwise use TypeSeq or ExpSeq based on your purpose.

In principle, renaming TypeTuple makes sense given it's bad name (though I 
really don't seem much point in separating expression tuples and type tuples), 
but it would break a _lot_ of code. And both Walter and Andrei are 
increasingly against making any breaking changes.

- Jonathan M Davis

Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples

[Andrei Alexandrescu]

On 9/25/12 3:39 PM, ixid wrote:

"T.expand" naturally has the connotation "unpacked" to me,


Isn't T.unpack clearer? Does that clash with a different usage for the
term?


Let's stay with .expand.

Andrei

Re: Is flags enum needed in Phobos?

[Faux Amis]

On 25/09/2012 20:03, bearophile wrote:

On Tuesday, 25 September 2012 at 17:13:44 UTC, Denis Shelomovskij wrote:

.NET has FlagsAttribute, Java has EnumSet. Looks like we need this
too. How about to add a library solution to Phobos?


See also:
http://d.puremagic.com/issues/show_bug.cgi?id=6946

Bye,
bearophile


comment on code:
Isn't there a way to retrieve all reserved words?

And, did you do a pull request?

Re: Is flags enum needed in Phobos?

[bearophile]

Faux Amis:


Isn't there a way to retrieve all reserved words?


I think the answer is negative.



And, did you do a pull request?


I don't do those yet. And that code is just a prototype.

Bye,
bearophile

Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples

[deadalnix]

Le 25/09/2012 17:51, ixid a écrit :

You've shown it's clearly incompatible with the current language and
would break lots of code. What would it break if assignment required
explicit tuple brackets?

(int a, b) = foo(); // A tuple assignment, 'a' and 'b' will be filled in
order by the multiple return values of foo()

int foo() {
return 1;
}

(int a, b) = foo(); // Also valid and only sets 'a'


int, int foo() {
return 1, 2;
}

int a = foo(); // Also valid and 'a' takes the first tuple value

(int a, auto b) = foo(); // Evaluated left to right so 'a' will take the
first argument of foo and b will auto to a type or tuple of what
remains. It will error if there is nothing remaining for b. This would
still allow the clean expression of stand-alone tuples and function
arguments and return values.

int, string a = 1, "hello";
int, string foo(double, double a) {
return cast(int) (d[0] * d[1]), "hello";
}



WTF are thoses affirmations ?

Re: implicit conversion from bool to char, is it really necessary ?

[deadalnix]

Le 25/09/2012 21:24, bearophile a écrit :

deadalnix:


bool b; // Defined elsewhere.
string s = "somestring" ~ b?"":"somemorestring";


bool => char implicit conversion is not commonly useful in programs, but
I think it's also not a common bug.



Thi sis reversed logic. bool => char have know drawback. So it must 
bring something at least as important as the drawback (whatever how 
small it is) involved.


I also wanted to discuss this subject specifically because it was a 
surprise to me and to other people on IRC. So I guess this feature is 
counter intuitive and contradict the rule that state that thing should 
work the way you expect them to work.


I also already knew that ?: were sometime confusing. However, I skipped 
on that because I was sure (and wrong) that a type error would be triggered.


It is a surprising behavior, so something you want to avoid as much as 
possible when creating a programing language.



On the other hand in past we have discussed a little about the bug-prone
precedence of the ?: operator. Analysis of shared code repositories
shows that this is a common source of bugs. So I think avoiding this bug
has higher priority (and it's enough to avoid your specific bug).

One of the ideas for D was that when the ?: is included in a larger
expression, to requires parentheses around it.

auto x1 = y1 ? z1 : w1; // OK
auto x2 = x0 + (y1 ? z1 : w1); // OK
auto x3 = (x0 + y1) ? z1 : w1); // OK
auto x4 = x0 + y1 ? z1 : w1; // error
auto x5 = y1 ? z1 : (y2 ? z2 : w2); // OK
auto x6 = y1 ? z1 : y2 ? z2 : w2; // error

In theory this increases the number of parentheses a little, but in
practice in many similar situations I already put those parentheses, for
readability and to avoid some of my mistakes.

Bye,
bearophile


This would solve my particular bug, and I think it is a good thing to 
make this clearer.

Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples

[ixid]

I meant to reply to your post rather than Jacob's.

Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples

[deadalnix]

Le 25/09/2012 17:08, Andrei Alexandrescu a écrit :

On 9/25/12 10:05 AM, deadalnix wrote:

OK, my bad. It means that tuple(...) behave differently than T...
defined tuples.

And both behave differently than Caml or Haskell's tuples.

isn't the time for some unification ? Preferably on how tuples work in
other languages, except if limitations can be shown and better proposal
are made (and not include that in D2.xxx).


I'm not sure actually. The way I look at it, built-in tuples are quite
low-level (types can't be spelled, automatic expansion and flattening,
undecided first-class semantics) and should seldom be dealt with
directly. The best use of built-in tuples is in the implementation of
truly well-behaved, composable tuples.

Andrei


We currently have 2 type of tuples, both unsatisfying it its own way 
(and I assume I can say it is confusing as I was confused before).


If the new tuple stuff is implemented, D will ends up with 3 tuples 
systems, 2 of them unsatisfying and 1 of them satisfying (at least that 
is the goal).


Still, language complexity would have increased in the process and have 
3 time the same feature with different flavor isn't a good thing. Even 
if the tuple solution is a good one, the resulting situation isn't.

Re: Function prototype + definition in the same file

[Steven Schveighoffer]

On Tue, 25 Sep 2012 16:07:51 -0400, Jonathan M Davis   
wrote:



On Tuesday, September 25, 2012 15:48:11 Steven Schveighoffer wrote:
On Tue, 25 Sep 2012 15:23:50 -0400, deadalnix   
wrote:

> Le 25/09/2012 20:57, Maxim Fomin a écrit :
>> On Tuesday, 25 September 2012 at 17:48:46 UTC, deadalnix wrote:
>>> This is code duplication and is generally considered as a bad
>>> practice. I'm not convinced that the language should be modified to
>>> allow something that is known as bad practice.
>>>
>>> What you need here is a more robust di generator IMO.
>>
>> This is neither a code duplication (there is certain distinction  
between
>> prototype and body) nor a bad practice - this is a common pattern in  
C
>> and C++. It is surprising that D cannot do such a simple thing which  
in

>> addition is not harmless, so there is no sense in depreciating it.
>
> This is code duplication. And this has been considered a problem in
> C/C++ for a while now.

No, it's a prototype.

Note that it's *required* if you want to hide implementation using .di
files.

There is no code involved, it's just generating a symbol reference in  
the

object file.


It's still code duplication, because you've now listed the function  
signature
twice. Yes, it's minimal code duplication, but it's still duplicating  
code.


I misunderstood, I was thinking in terms of generated code.

But in any case, it's still not duplicated code.  What you are doing is  
defining an interface, then attaching the implementation of the interface  
to the declaration by repeating its name.


Would you say repeating the function signature of an interface in an  
implementing class is code duplication?  Would you say that typing the  
name of a variable that you already declared so you could access it is  
code duplication?


Duplicated or not, it's still valid under the spec as far as I can tell.


It's necessary for stuff like .di files (which are code duplication by
definition, because they're duplicating a module - or at least part of  
it), but
most everyone I know has thought (where it's come anyway) that  
prototypes were

a _bad_ thing about C/C++.


The main reason for having prototypes in C/C++ was so you could declare a  
symbol that you weren't defining yet.


In some cases, this was necessary, because C/C++ does not have forward  
references.  So there is indeed very little reason in D to declare a  
function, then implement it in the same file.


But I think what Manu is trying to do is not exactly just "repeat the  
signature", he is using the signature of the original to generate the  
signature of the auto-generated function.  Essentially, it's not  
duplicated code on either the source or the compiled level, so disabling  
the ability to declare a function and then implement it later would  
prevent this possibility.  I don't think it makes sense to do that.


-Steve

Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples

[Nick Sabalausky]

On Tue, 25 Sep 2012 12:07:33 +0200
deadalnix  wrote:

> Le 25/09/2012 09:11, Jacob Carlborg a écrit :
> > On 2012-09-25 00:28, bearophile wrote:
> >
> >> (||)
> >> (|1|)
> >> (|1, 2|)
> >> (|1, 2, 3|)
> >
> > What about:
> >
> > ||
> > |1|
> > |1, 2|
> >
> 
> Yeah and why not þ1, 2þ or ŀ1, 2ŀ ?
> 
> maybe ↓1, 2↓ is better ?
> 
> or « 1, 2 » (this one at least is readable).

| is easily typed. þ, ŀ, ↓ and « I had to copy-paste.

Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples

[Andrei Alexandrescu]

On 9/25/12 4:37 PM, deadalnix wrote:

Le 25/09/2012 17:08, Andrei Alexandrescu a écrit :

On 9/25/12 10:05 AM, deadalnix wrote:

OK, my bad. It means that tuple(...) behave differently than T...
defined tuples.

And both behave differently than Caml or Haskell's tuples.

isn't the time for some unification ? Preferably on how tuples work in
other languages, except if limitations can be shown and better proposal
are made (and not include that in D2.xxx).


I'm not sure actually. The way I look at it, built-in tuples are quite
low-level (types can't be spelled, automatic expansion and flattening,
undecided first-class semantics) and should seldom be dealt with
directly. The best use of built-in tuples is in the implementation of
truly well-behaved, composable tuples.

Andrei


We currently have 2 type of tuples, both unsatisfying it its own way
(and I assume I can say it is confusing as I was confused before).

If the new tuple stuff is implemented, D will ends up with 3 tuples
systems, 2 of them unsatisfying and 1 of them satisfying (at least that
is the goal).

Still, language complexity would have increased in the process and have
3 time the same feature with different flavor isn't a good thing. Even
if the tuple solution is a good one, the resulting situation isn't.


I agree. That's why I want to take the minimum amount of steps to make 
library tuples work. That minimum amount may be 1, i.e. just implement 
deconstruction.


Andrei

Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples

[Andrei Alexandrescu]

On 9/25/12 4:14 PM, Jonathan M Davis wrote:

On Wednesday, September 26, 2012 04:29:13 kenji hara wrote:

But, the two are often confused, by the word "tuple". It has
introduced badly confusion in many discussions.
To make matters worse, it had often invoked incorrect suggestion that
merging the two into one.

My suggestion is very simple.
1. Change all words "built-in tuple" in the documentation to "built-in
sequence". Then, in the D language world, we can have clarify name for
the built-in one.
2. Introduce new templates, Seq, TypeSeq, and ExpSeq.

template Seq(T...) { alias T Seq; } // identical with
std.typetuple.TypeTuple
template TypeSeq(T...) if (allSatisfy!(isType, T)) { alias T TypeSeq; }
template ExpSeq(T...) if (allSatisfy!(isExpression, T)) { alias T
ExpSeq; }

If you really want to a sequence with heterogeneous elements, use
Seq template. Otherwise use TypeSeq or ExpSeq based on your purpose.


In principle, renaming TypeTuple makes sense given it's bad name (though I
really don't seem much point in separating expression tuples and type tuples),
but it would break a _lot_ of code. And both Walter and Andrei are
increasingly against making any breaking changes.

- Jonathan M Davis


TypeTuple does a lot of harm. I'd be glad to rename it GenericTuple and 
leave TypeTuple as a slowly rotting alias.


Andrei

Re: Is flags enum needed in Phobos?

[bearophile]

Faux Amis:


Isn't there a way to retrieve all reserved words?


This is a possibility:

assert(__traits(is_reserved_word, "import"));

Bye,
bearophile

Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples

[Jonathan M Davis]

On Tuesday, September 25, 2012 22:39:37 ixid wrote:
> I meant to reply to your post rather than Jacob's.

It would help if you actually quoted at least _some_ of the post that you're 
replying to. I have _no_ idea what post you're replying to here. Many people 
view this newsgroup without any threading (meaning that your post is _really_ 
confusing), and even when you _have_ threading, it doesn't always work right 
(my mail client frequently puts posts in the wrong place in the hierarchy). 
So, please include at least some of the posts that you're replying to in your 
replies.

- Jonathan M Davis

Re: Should this be flagged as a warning?

[bearophile]

Bernard Helyer:


match(ts, TokenType.Is);
match(ts, TokenType.OpenParen);
isExp.type == parseType(ts);

The bug being of course, that a type is parsed and ts is 
modified, so the expression has side effects so it's not

flagged as a useless expression. But the comparison still
has no effect, so should this be flagged by DMD?


The top level operation is the ==, that is a pure expression, so 
maybe dmd should warn on this.


Bye,
bearophile

Re: Should this be flagged as a warning?

[Bernard Helyer]

On Tuesday, 25 September 2012 at 19:29:26 UTC, Bernard Helyer 
wrote:
I tried to post this last night, but the NG wasn't having any 
of it.


I found myself writing a bug that looked like this

match(ts, TokenType.Is);
match(ts, TokenType.OpenParen);
isExp.type == parseType(ts);

The bug being of course, that a type is parsed and ts is 
modified,
so the expression has side effects so it's not flagged as a 
useless

expression.


Err, the bug is that I wrote '==' instead of '='. That's what
I get for posting first thing in the morning, I guess.

Re: implicit conversion from bool to char, is it really necessary ?

[bearophile]

deadalnix:

Thi sis reversed logic. bool => char have know drawback. So it 
must bring something at least as important as the drawback 
(whatever how small it is) involved.


I agree that implicit conversion from bool to char sounds useless 
or bad. But you already have a D2 language that few people use, 
so to break their code you need an important enough reason :-(


Beside requiring the parentheses about the ?: operator when it's 
part of a larger expression, there are one or two other patterns 
that I'd like to see disallowed in D, like (!x & y). I think 
Walter agreed on disallowing it, but I have not heard about it 
since some time:


http://d.puremagic.com/issues/show_bug.cgi?id=5409

Bye,
bearophile

Re: Should this be flagged as a warning?

[Bernard Helyer]

On Tuesday, 25 September 2012 at 21:15:24 UTC, bearophile wrote:
The top level operation is the ==, that is a pure expression, 
so maybe dmd should warn on this.


Yeah, I thought so but I'm not sure. Hence me asking.

Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples

[ixid]

On Tuesday, 25 September 2012 at 10:04:46 UTC, deadalnix wrote:

Le 25/09/2012 03:19, ixid a écrit :
What would a special case where the first level of tuple (with 
higher
levels being tuples in tuples) didn't require parens break? 
This would

be a beautiful syntax:

auto a = 1, 2; // A tuple of two ints

int, string fun(double, double d) {
return cast(int) (d[0] * d[1]), "hello";
}

auto a, b = 1, 2; // Two ints
auto a = fun(1.0, 1.0); // Tuple of 1 and "hello".
auto a, b = fun(1.0, 1.0); // An int and a string.



It can get pretty confusing with , separated declarations :

int a, b = 3;

or worse :

int a, int b = foo();
-->
(int a, int b) = foo();
  or
int a, (int b = foo());

and it gets worse with int a, auto b = foo();

But I do agree that this is really nice in many places.


Replying to the correct post this time, sorry for the repeated 
posting.


You've shown it's clearly incompatible with the current language
and would break lots of code. What would it break if assignment
required explicit tuple brackets?

(int a, b) = foo(); // A tuple assignment, 'a' and 'b' will be
filled in order by the multiple return values of foo()

int foo() {
return 1;
}

(int a, b) = foo(); // Also valid and only sets 'a'


int, int foo() {
return 1, 2;
}

int a = foo(); // Also valid and 'a' takes the first tuple value

(int a, auto b) = foo(); // Evaluated left to right so 'a' will
take the first argument of foo and b will auto to a type or tuple
of what remains. It will error if there is nothing remaining for
b. This would still allow the clean expression of stand-alone
tuples and function arguments and return values.

int, string a = 1, "hello";
int, string foo(double, double a) {
   return cast(int) (d[0] * d[1]), "hello";
}

Doesn't the needs of bracketing to determine order operation,
(stuff) more or less imply that implicit conversion between one
member tuples and the type of that tuple member is a requirement?
Or would the (stuff, ) syntax be better?

Re: [OT] Was: totally satisfied :D

[Nick Sabalausky]

On Tue, 25 Sep 2012 08:10:07 -0700
"H. S. Teoh"  wrote:
> On Mon, Sep 24, 2012 at 09:55:48PM -0400, Nick Sabalausky wrote:
> > For my usual mailboxes though, I prefer typical GUI desktop clients.
> > Unfortunately, I still haven't been able to find one that I like.
> 
> Maybe you should write one in D. ;-)
> 

Heh, I'd love to, and I've even had that in mind for some time now (a
few years). Problem is there's a *lot* of things I'd like to do, and all
on top of other things I *have* to do ;)

My current pet project ATM is a blog^H^H^H^H*article* system using
vibe.d and Adam's HTML DOM (the combination of which are making
development a *breeze*...in the rare cases I actually get to work on
it). It won't be as fully-featured as wordpress or tangocms, but at
least it'll do what I want, how I want, and won't go anywhere near
PHP ;)

> For one thing, having a MIME library in D would be awesome.
> 

Maybe I'm just not awake enough yet but: What exactly would it do? Just
be a mapping of "file extension" <--> "mime type"?

> 
> I'm a big Opera fan, because Opera lets me configure stuff to work the
> way I want it to. But I never use it for mail (I don't like using a
> browser as an MUA, I think that's just feeping creaturism). And recent
> releases of Opera are starting to show signs of instability and
> excessive memory consumption, unlike earlier releases, and I'm
> starting to wonder if I might want to switch to Firefox...
> 

Newer Operas also got rid of the "native-ish" theme, which is why I'm
not upgrading past v10. It may seem trivial, but skinned apps *really*
bug me.

I find the UIs in the FF4-onward to be completely intolerable. Even
FF3's UI was god-awful, and then they managed to make it worse with 4 by
going all "Chrome-envy".


> ... but if it's that unconfigurable, then Opera might just be the
> lesser of two evils. I have to admit that I've tried using Firefox as
> my primary browser before, and I didn't like it. It's too IE-like for
> my tastes.
> 

That was probably a long time ago, as FF is basically a Chrome
knock-off now. Then again, so is IE now...

Speaking of, I wrote a "not-a-blog" post about these browser issues just
a few months back:



(Yea, TangoCMS uses lng urls.)

> The result is that people revert to using table-based formatting and

Hey, I *like* table-based formatting :). Beats the hell out of trying to
kluge together sane layouts/flowing with CSS. And nobody's
ever going to convince me that HTML isn't the presentation layer.

Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples

[Andrei Alexandrescu]

On 9/25/12 4:44 PM, Jonathan M Davis wrote:

On Tuesday, September 25, 2012 22:39:37 ixid wrote:

I meant to reply to your post rather than Jacob's.


It would help if you actually quoted at least _some_ of the post that you're
replying to. I have _no_ idea what post you're replying to here. Many people
view this newsgroup without any threading (meaning that your post is _really_
confusing), and even when you _have_ threading, it doesn't always work right
(my mail client frequently puts posts in the wrong place in the hierarchy).
So, please include at least some of the posts that you're replying to in your
replies.

- Jonathan M Davis


Also, ixid, while you're at it, don't _forget_ to _underline_ all 
_words_ that are _important_.


_Andrei_

Ch-ch-changes

[Andrei Alexandrescu]

Hello all,


There's quite a few changes that we're very excited about, that I'd love 
to share to the extent possible.


First, we have decided to extend commit rights to Daniel Murphy and 
Martin Nowak, two heavyweight dmd contributors better known under their 
noms de plume: yebblies and dawgfoto, respectively. Please join me in 
congratulating them for this token of appreciation for their talent and 
hard work.


We want to move dmd forward faster, and we're encouraging committers to 
be more aggressive about reviewing and merging patches. Language changes 
will still have to get through Scylla and Charybdis (that's Walter and 
yours truly), but bug fixes and other non-controversial work can be 
safely parallelized.


Here's a small draft to guide contributors to the compiler proper: 
http://www.prowiki.org/wiki4d/wiki.cgi?Contributing_To_The_D_Compiler. 
It's mostly authored by Don, and we should all add to it sections and 
topics that we consider relevant. At a later point we'll link to the 
document from the website, or integrate it there.


We also want to formalize and automate our processes, including building 
the compiler and its libraries, testing it all, contributing, website, 
and so on. We believe that's a prerequisite to handle (and indeed 
condition) the projected growth of the language. To that end, we'll try 
to define and use a build and release procedure. There's been talk about 
a git workflow; if anyone wants to volunteer creating a detailed 
document describing the steps done, that would be awesome.


Last but not least, we're in talks with a professional conference 
organizer about setting up a D conference. We're looking at some quite 
interesting approaches, but one invariant is that community 
participation and drive is key. We'll get back to you as details firm 
up; for now, lightly hash the months of April and May with a pencil.



Thanks,

Andrei

P.S. Speaking only for myself: there's been robust community growth and 
increase in participation in the past twelve months. It's also clear to 
me that although the resources we have now are fine for today's user 
base, we need to scale well in advance to what we project. By my 
estimates the community size is in the five digits now. To go 1-2 orders 
of magnitude higher, I estimate that continuing to do what we do today 
is far from enough, so we'll need to do some radical changes. Some may 
be risky, and some may be painful. But the as the guy in "Die Hard 2" 
said: no guts, no glory. Let's do this together.

Re: Ch-ch-changes

[Iain Buclaw]

On Tuesday, 25 September 2012 at 22:09:37 UTC, Andrei 
Alexandrescu wrote:

Hello all,


There's quite a few changes that we're very excited about, that 
I'd love to share to the extent possible.


First, we have decided to extend commit rights to Daniel Murphy 
and Martin Nowak, two heavyweight dmd contributors better known 
under their noms de plume: yebblies and dawgfoto, respectively. 
Please join me in congratulating them for this token of 
appreciation for their talent and hard work.


We want to move dmd forward faster, and we're encouraging 
committers to be more aggressive about reviewing and merging 
patches. Language changes will still have to get through Scylla 
and Charybdis (that's Walter and yours truly), but bug fixes 
and other non-controversial work can be safely parallelized.


Here's a small draft to guide contributors to the compiler 
proper: 
http://www.prowiki.org/wiki4d/wiki.cgi?Contributing_To_The_D_Compiler. 
It's mostly authored by Don, and we should all add to it 
sections and topics that we consider relevant. At a later point 
we'll link to the document from the website, or integrate it 
there.




Speaking of the 'front-end proper':
"Given that all back-ends share the same front-end, you should 
expect the same compatibility level across all compilers for a 
given compiler release."


Unfortunately, this is not quite the case yet. I'm in the middle 
of drafting something, but the ultimate goal is to get us all 
working together (dmd, gdc, ldc) so that there can genuinely be a 
shared, portable source base for the D front-end, used by all 
maintainers, without the neccesity to modify the original code, 
or use conditionals based on which compiler it's used in. eg: 
#ifdef IN_GCC, IN_LDC, IN_DMD...



Keep up the good work! :~)

Regards,
Iain.

Re: [OT] Was: totally satisfied :D

[H. S. Teoh]

On Tue, Sep 25, 2012 at 05:36:48PM -0400, Nick Sabalausky wrote:
> On Tue, 25 Sep 2012 08:10:07 -0700
> "H. S. Teoh"  wrote:
> > On Mon, Sep 24, 2012 at 09:55:48PM -0400, Nick Sabalausky wrote:
> > > For my usual mailboxes though, I prefer typical GUI desktop
> > > clients.  Unfortunately, I still haven't been able to find one
> > > that I like.
> > 
> > Maybe you should write one in D. ;-)
> > 
> 
> Heh, I'd love to, and I've even had that in mind for some time now (a
> few years). Problem is there's a *lot* of things I'd like to do, and
> all on top of other things I *have* to do ;)

Ah yes. I have that problem too. Too many pet projects, too little time.


[...]
> > For one thing, having a MIME library in D would be awesome.
> > 
> 
> Maybe I'm just not awake enough yet but: What exactly would it do?
> Just be a mapping of "file extension" <--> "mime type"?

I must've been half-asleep when I wrote that. I meant a mail-handling
library that can handle MIME attachments.


> > I'm a big Opera fan, because Opera lets me configure stuff to work
> > the way I want it to. But I never use it for mail (I don't like
> > using a browser as an MUA, I think that's just feeping creaturism).
> > And recent releases of Opera are starting to show signs of
> > instability and excessive memory consumption, unlike earlier
> > releases, and I'm starting to wonder if I might want to switch to
> > Firefox...
> > 
> 
> Newer Operas also got rid of the "native-ish" theme, which is why I'm
> not upgrading past v10. It may seem trivial, but skinned apps *really*
> bug me.

Skinned apps don't bug me at all. I tend to like apps where you can
delete useless buttons off the UI and turn off toolbars and stuff you
never use. As well as configure custom keyboard bindings ('cos I hate
having to use the mouse unless it's needed for an *inherently* graphical
task, like picking out pixels).


> I find the UIs in the FF4-onward to be completely intolerable. Even
> FF3's UI was god-awful, and then they managed to make it worse with 4
> by going all "Chrome-envy".

What I'd _really_ like, is browser *library*, where you get to assemble
your own browser from premade parts. Like replace the lousy UI front end
with a custom interface. Applications nowadays suffer from excessive
unnecessary integration. Software should be made reusable, dammit. And I
don't mean just code reuse on the level of functions. I mean entire
software systems that are pluggable and inter-connectible. If there's a
browser that has a good back-end renderer but lousy UI, it should be
possible to rip out the UI part and substitute it with the UI of another
browser that has a better UI but lousy back-end. And if there's a
browser that comes with unnecessary bloat like a mail app, it should be
possible to outright _delete_ the mail component off the HD and have
just the browser part working. Software these days is just so monolithic
and clumsy. We need a new paradigm.


[...]
> > The result is that people revert to using table-based formatting and
> 
> Hey, I *like* table-based formatting :). Beats the hell out of trying
> to kluge together sane layouts/flowing with CSS. And nobody's ever
> going to convince me that HTML isn't the presentation layer.

I say trash it all, tables, HTML, everything. Markdown is good enough
for email. If you need more than that, go buy a real website and post it
there instead of transmitting that crap over SMTP.


T

-- 
This is a tpyo.

Re: Ch-ch-changes

[Ben Davis]

Seems like as good a time as any to say how awesome I think D is, and 
how much the world needs it! Where I work, we have a monstrosity of a 
project using all of Java, C++ and Lua, with all three interoperating in 
all directions. We've been asked to write all new code in C++ for 
reasons of portability. Having used Java extensively and D a little, I. 
Cannot. Stand. The. Pain. Of. Need for header files, lack of automatic 
memory initialisation, lack of decent IDE support because the language 
is just that bad... So while they're right about Java not being 
portable, I'm holding out and continuing to write in Java anyway. :)


So I absolutely want D to grow and get the support it needs to be able 
to replace C++, and the sooner the better! Go D! :)


(Normally I'd worry how many people I just offended, but probably not 
here :D)


On 25/09/2012 23:10, Andrei Alexandrescu wrote:

Hello all,


There's quite a few changes that we're very excited about, that I'd love
to share to the extent possible.

First, we have decided to extend commit rights to Daniel Murphy and
Martin Nowak, two heavyweight dmd contributors better known under their
noms de plume: yebblies and dawgfoto, respectively. Please join me in
congratulating them for this token of appreciation for their talent and
hard work.

We want to move dmd forward faster, and we're encouraging committers to
be more aggressive about reviewing and merging patches. Language changes
will still have to get through Scylla and Charybdis (that's Walter and
yours truly), but bug fixes and other non-controversial work can be
safely parallelized.

Here's a small draft to guide contributors to the compiler proper:
http://www.prowiki.org/wiki4d/wiki.cgi?Contributing_To_The_D_Compiler.
It's mostly authored by Don, and we should all add to it sections and
topics that we consider relevant. At a later point we'll link to the
document from the website, or integrate it there.

We also want to formalize and automate our processes, including building
the compiler and its libraries, testing it all, contributing, website,
and so on. We believe that's a prerequisite to handle (and indeed
condition) the projected growth of the language. To that end, we'll try
to define and use a build and release procedure. There's been talk about
a git workflow; if anyone wants to volunteer creating a detailed
document describing the steps done, that would be awesome.

Last but not least, we're in talks with a professional conference
organizer about setting up a D conference. We're looking at some quite
interesting approaches, but one invariant is that community
participation and drive is key. We'll get back to you as details firm
up; for now, lightly hash the months of April and May with a pencil.


Thanks,

Andrei

P.S. Speaking only for myself: there's been robust community growth and
increase in participation in the past twelve months. It's also clear to
me that although the resources we have now are fine for today's user
base, we need to scale well in advance to what we project. By my
estimates the community size is in the five digits now. To go 1-2 orders
of magnitude higher, I estimate that continuing to do what we do today
is far from enough, so we'll need to do some radical changes. Some may
be risky, and some may be painful. But the as the guy in "Die Hard 2"
said: no guts, no glory. Let's do this together.

Re: Ch-ch-changes

[bearophile]

Andrei Alexandrescu:

I estimate that continuing to do what we do today is far from 
enough, so we'll need to do some radical changes. Some may be 
risky, and some may be painful. But the as the guy in "Die Hard 
2" said: no guts, no glory. Let's do this together.


Currently the D community is still small, so I suggest to add 
this link to the D home page:

http://rosettacode.org/wiki/Category:D

Bye,
bearophile

Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples

[Timon Gehr]

On 09/25/2012 11:01 PM, Andrei Alexandrescu wrote:

On 9/25/12 4:14 PM, Jonathan M Davis wrote:

On Wednesday, September 26, 2012 04:29:13 kenji hara wrote:

But, the two are often confused, by the word "tuple". It has
introduced badly confusion in many discussions.
To make matters worse, it had often invoked incorrect suggestion that
merging the two into one.

My suggestion is very simple.
1. Change all words "built-in tuple" in the documentation to "built-in
sequence". Then, in the D language world, we can have clarify name for
the built-in one.
2. Introduce new templates, Seq, TypeSeq, and ExpSeq.

template Seq(T...) { alias T Seq; } // identical with
std.typetuple.TypeTuple
template TypeSeq(T...) if (allSatisfy!(isType, T)) { alias T TypeSeq; }
template ExpSeq(T...) if (allSatisfy!(isExpression, T)) { alias T
ExpSeq; }

If you really want to a sequence with heterogeneous elements, use
Seq template. Otherwise use TypeSeq or ExpSeq based on your purpose.


In principle, renaming TypeTuple makes sense given it's bad name
(though I
really don't seem much point in separating expression tuples and type
tuples),
but it would break a _lot_ of code. And both Walter and Andrei are
increasingly against making any breaking changes.

- Jonathan M Davis


TypeTuple does a lot of harm. I'd be glad to rename it GenericTuple and
leave TypeTuple as a slowly rotting alias.

Andrei


I'd never use GenericTuple, because already after four usages it would
have been cheaper to just define Seq inline.

GenericTupleGenericTupleGenericTupleGenericTuple
template Seq(T...){ alias T Seq; }SeqSeqSeqSeq

What is the rationale for calling this construct a tuple anyway?
Programming language tuples usually impose more structure on the
data than just ordering.

Re: Ch-ch-changes

[Andrei Alexandrescu]

On 9/25/12 6:31 PM, Iain Buclaw wrote:

Speaking of the 'front-end proper':
"Given that all back-ends share the same front-end, you should expect
the same compatibility level across all compilers for a given compiler
release."

Unfortunately, this is not quite the case yet. I'm in the middle of
drafting something, but the ultimate goal is to get us all working
together (dmd, gdc, ldc) so that there can genuinely be a shared,
portable source base for the D front-end, used by all maintainers,
without the neccesity to modify the original code, or use conditionals
based on which compiler it's used in. eg: #ifdef IN_GCC, IN_LDC, IN_DMD...


That's great, keep us posted.


Keep up the good work! :~)


Well right back atcha.


Andrei

Re: [OT] Was: totally satisfied :D

[Adam D. Ruppe]

On Tuesday, 25 September 2012 at 22:49:36 UTC, H. S. Teoh wrote:
I must've been half-asleep when I wrote that. I meant a 
mail-handling library that can handle MIME attachments.


I did a simple one a while ago. Jush pushed to github:

https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff/blob/fd7bfd5c250901a8c546b502772f18fe019ed7e9/email.d

Nothing really special, but it works for what I've tried with it 
so far.


I need to do a parser soon too, to replace my current indexOf 
hacks in my mail reading apps. Eh, I'll get around to it 
eventually.

Re: DIP19: Remove comma operator from D and provision better syntactic support for tuples

[Timon Gehr]

On 09/25/2012 09:29 PM, kenji hara wrote:

2012/9/26 Jonathan M Davis :

On Tuesday, September 25, 2012 13:45:50 Michel Fortin wrote:

On 2012-09-25 16:38:31 +, "Jonathan M Davis"  said:

On Tuesday, September 25, 2012 12:28:15 Michel Fortin wrote:

Although to make things less confusing, I think the built-in language
tuple should give up its name. It could become a "sequence". Renaming
the built-in one would certainly be less trouble, as code doesn't refer
to it by its name, and you can pick a name that fits better with its
auto-expanding behaviour.


Not referred to by its name? It's refereed to as TypeTuple all over the
place. It's arguably a bad name, but it would break a _lot_ of code to
change it now.

TypeTuple is only a construct allowing you to create a built-in
language tuple, one that does not necessarily match the definition of a
TypeTuple. The language spec defines a Tuples, TypeTuples, and
ExpressionTuples with these words (ironically, using the word
"sequence" twice):

"""
If the last template parameter in the TemplateParameterList is declared
as a TemplateTupleParameter, it is a match with any trailing template
arguments. The sequence of arguments form a Tuple. A Tuple is not a
type, an expression, or a symbol. It is a sequence of any mix of types,
expressions or symbols.

A Tuple whose elements consist entirely of types is called a TypeTuple.
A Tuple whose elements consist entirely of expressions is called an
ExpressionTuple.
"""
Source: http://dlang.org/template.html


I wasn't aware of that being in the language definition, but it doesn't change
the fact that they're used and referred to in code as TypeTuple, and renaming
that would break a lot of code. And it _is_ used for the built-in tuple type,
regardless of whether the spec considers the terms type tuple and expression
tuple to refer to distinct entities. Rename the stuff in the spec to whatever
you like, but the library uses the term TypeTuple, so it _is_ used in code.

- Jonathan M Davis


I like current design - open (built-in, automatically flattened, and
*unpacked*) tuple, and closed (library, be structured, and *packed*)
tuple.

But, the two are often confused, by the word "tuple". It has
introduced badly confusion in many discussions.
To make matters worse, it had often invoked incorrect suggestion that
merging the two into one.

My suggestion is very simple.
1. Change all words "built-in tuple" in the documentation to "built-in
sequence". Then, in the D language world, we can have clarify name for
the built-in one.
2. Introduce new templates, Seq, TypeSeq, and ExpSeq.

 template Seq(T...) { alias T Seq; }// identical with
std.typetuple.TypeTuple


+1.


 template TypeSeq(T...) if (allSatisfy!(isType, T)) { alias T TypeSeq; }
 template ExpSeq(T...) if (allSatisfy!(isExpression, T)) { alias T ExpSeq; }

   If you really want to a sequence with heterogeneous elements, use
Seq template. Otherwise use TypeSeq or ExpSeq based on your purpose.

Kenji Hara



I don't consider TypeSeq and ExpSeq crucial. They do not do more
checking than using the sequence in type or expression context triggers
automatically, but YMMV.