Re: Tuple assignment

[Walter Bright]

Russel Winder wrote:

Python may be the best base to compare things to as tuple assignment has
been in there for years.

Pythons choice is not a car/cdr approach but an exact match approach.
so if t represents a tuple datum or a function returning a tuple:

x = t

then x is a tuple -- remembering that variables are all just references
to objects implemented via keys in a dictionary, and:

a , b , c = t
or
( a , b , c ) = t

is tuple assignment where now t is required to be a tuple of length 3.
cf.


The first thought was to make it an exact match approach. Andrei thought that 
the car/cdr one was better, though, and I find it intuitively appealing, too. 
Perhaps Python missed an important use case?


Or perhaps the ambiguity as to whether the last item gets to be a value or 
another tuple is too much.

Re: Tuple assignment

[Walter Bright]

Russel Winder wrote:

Python may be the best base to compare things to as tuple assignment has
been in there for years.


Too segue this into the previous thread, how does Python treat (1)? Is it a 
floor wax or a dessert topping?


http://www.nbc.com/saturday-night-live/video/shimmer-floor-wax/1056743/

Re: Tuple assignment

[Denis Koroskin]

On Thu, 07 Oct 2010 10:43:18 +0400, Russel Winder   
wrote:



On Wed, 2010-10-06 at 23:08 -0700, Walter Bright wrote:
If expr represents a tuple, we (Andrei and I) were thinking about the  
syntax:


 auto (a, b, c, d) = expr;

being equivalent to:

 auto t = expr; auto a = t[0]; auto b = t[1]; auto c = t[2 .. $];

You can also do this with arrays, such that:

 float[3] xyz;
 auto (x, y, z) = xyz;

The Lithpers among you will notice that this essentially provides a  
handy

car,cdr shortcut for tuples and arrays:

 auto (car, cdr) = expr;



Python may be the best base to compare things to as tuple assignment has
been in there for years.

Pythons choice is not a car/cdr approach but an exact match approach.
so if t represents a tuple datum or a function returning a tuple:

x = t

then x is a tuple -- remembering that variables are all just references
to objects implemented via keys in a dictionary, and:

a , b , c = t
or
( a , b , c ) = t

is tuple assignment where now t is required to be a tuple of length 3.
cf.


|> python
Python 2.6.5 (r265:79063, Apr 16 2010, 13:57:41)
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more  
information.

>>> t = ( 1 , 'fred' , 2.0 )
>>> x = t
>>> print x
(1, 'fred', 2.0)
>>> a , b , c = t
>>> print a , b , c
1 fred 2.0
>>> a , b = t
Traceback (most recent call last):
  File "", line 1, in 
ValueError: too many values to unpack
>>> a , b , c , d = t
Traceback (most recent call last):
  File "", line 1, in 
ValueError: need more than 3 values to unpack
>>>




That's because Python is not a strictly typed language. With proper type  
propagation compiler helps you writing code the way in meant to be. E.g.  
the following:


(a, b, c, d) = ('tuple', 'of', 'three')

could be statically disabled, but there is nothing wrong with allowing it  
either: d would be just a no-op, you will know it for sure the moment you  
try using it.

Re: Tuple assignment

[Brad Roberts]

On 10/6/2010 11:58 PM, Walter Bright wrote:
> Russel Winder wrote:
>> Python may be the best base to compare things to as tuple assignment has
>> been in there for years.
>>
>> Pythons choice is not a car/cdr approach but an exact match approach.
>> so if t represents a tuple datum or a function returning a tuple:
>>
>> x = t
>>
>> then x is a tuple -- remembering that variables are all just references
>> to objects implemented via keys in a dictionary, and:
>>
>> a , b , c = t
>> or
>> ( a , b , c ) = t
>>
>> is tuple assignment where now t is required to be a tuple of length 3.
>> cf.
> 
> The first thought was to make it an exact match approach. Andrei thought that
> the car/cdr one was better, though, and I find it intuitively appealing, too.
> Perhaps Python missed an important use case?
> 
> Or perhaps the ambiguity as to whether the last item gets to be a value or
> another tuple is too much.

I think the ambiguity should be avoided.  There was one language I used ages ago
that used a token to signal the use of the last arg as a 'rest' usage.  If I
remember right, it used:

  (a, @b) = aggregate; // a = aggregate[0], b = aggregate[1..$]

It also allowed: (a, @aggregate) = aggregate; // essentially a pop operation.

That said, it was a weakly typed language, so it's application to D has to be
taken with an appropriate dose of salt.  For D, I think using the @ would clash
badly with the attribute syntax, so an alternative that's not horrid:

   (a, b...) = aggregate;

Later,
Brad

Re: Tuple literal syntax

[Juanjo Alvarez]

On Wed, 06 Oct 2010 23:04:35 -0700, Walter Bright 
 wrote:

(a,0)[0]





as how a user could generate a tuple of 1. Awkward, sure, but like 
I said, I 

think this would be rare.


Python uses:

(5,) 


Which is a lot better IMHO

Re: Tuple literal syntax

[Denis Koroskin]

On Thu, 07 Oct 2010 10:04:35 +0400, Walter Bright  
 wrote:



There have been a couple of looong threads about tuples:

http://www.digitalmars.com/d/archives/digitalmars/D/Reddit_why_aren_t_people_using_D_93528.html

http://www.digitalmars.com/d/archives/digitalmars/D/Should_the_comma_operator_be_removed_in_D2_101321.html

A lot of it foundered on what the syntax for tuple literals should be.  
The top of the list is simply enclosing them in ( ). The problem with  
this is


  (expression)

Is that a parenthesized expression, or a tuple? This really matters,  
since (e)[0] means very different things for the two. Finally, I got to  
thinking, why not just make it a special case:



  ( ) == tuple
  (a) == parenthesized expression
  (a,b) == tuple
  (a,b,c) == tuple
  (a,b,c,d) == tuple

etc.

No ambiguities! Only one special case. I submit this special case is  
rare, because who wants to define a function that returns a tuple of 1?  
Such will come about from generative programming, but:


(a,b,c)[0]

may be how the generative programming works, and that suggests:

(a,0)[0]

as how a user could generate a tuple of 1. Awkward, sure, but like I  
said, I think this would be rare.


If tuples become first-class citizens of D lands, is it possible to make  
'void' and alias to an empty tuple? I believe they are basically the same  
thing. A function that accepts no arguments may be defined as a function  
that accepts a tuple of size 0:


void f1(string, string);
auto tuple1 = ("hello, %s", "world");

f1(tuple1); // works

void f2();
auto tuple2 = ();
f2(tuple2); // should work, too

That would allow creation a variables of type void, which is very useful  
for generic programming. Here is an example:


auto proxy(alias f)()
{
auto result = f();
do(stuff);
return result;
}

Works for any functions 'f' but returning voids.

I know it have been asked many times with no success, but still...

Re: Tuple literal syntax

[Don]

Juanjo Alvarez wrote:
On Wed, 06 Oct 2010 23:04:35 -0700, Walter Bright 
 wrote:

(a,0)[0]





as how a user could generate a tuple of 1. Awkward, sure, but like 

I said, I

think this would be rare.


Python uses:

(5,)
Which is a lot better IMHO


I agree, that would fit well with the optional trailing commas in array 
literals.

Re: Tuple assignment

[Denis Koroskin]

On Thu, 07 Oct 2010 11:42:06 +0400, Brad Roberts   
wrote:



On 10/6/2010 11:58 PM, Walter Bright wrote:

Russel Winder wrote:
Python may be the best base to compare things to as tuple assignment  
has

been in there for years.

Pythons choice is not a car/cdr approach but an exact match approach.
so if t represents a tuple datum or a function returning a tuple:

x = t

then x is a tuple -- remembering that variables are all just references
to objects implemented via keys in a dictionary, and:

a , b , c = t
or
( a , b , c ) = t

is tuple assignment where now t is required to be a tuple of length 3.
cf.


The first thought was to make it an exact match approach. Andrei  
thought that
the car/cdr one was better, though, and I find it intuitively  
appealing, too.

Perhaps Python missed an important use case?

Or perhaps the ambiguity as to whether the last item gets to be a value  
or

another tuple is too much.


I think the ambiguity should be avoided.  There was one language I used  
ages ago
that used a token to signal the use of the last arg as a 'rest' usage.   
If I

remember right, it used:

  (a, @b) = aggregate; // a = aggregate[0], b = aggregate[1..$]

It also allowed: (a, @aggregate) = aggregate; // essentially a pop  
operation.


That said, it was a weakly typed language, so it's application to D has  
to be
taken with an appropriate dose of salt.  For D, I think using the @  
would clash

badly with the attribute syntax, so an alternative that's not horrid:

   (a, b...) = aggregate;

Later,
Brad


Interesting idea, I like it!

Re: Tuple literal syntax

[Andrei Alexandrescu]

On 10/7/10 1:04 CDT, Walter Bright wrote:

There have been a couple of looong threads about tuples:

http://www.digitalmars.com/d/archives/digitalmars/D/Reddit_why_aren_t_people_using_D_93528.html


http://www.digitalmars.com/d/archives/digitalmars/D/Should_the_comma_operator_be_removed_in_D2_101321.html


A lot of it foundered on what the syntax for tuple literals should be.
The top of the list is simply enclosing them in ( ). The problem with
this is

(expression)

Is that a parenthesized expression, or a tuple? This really matters,
since (e)[0] means very different things for the two. Finally, I got to
thinking, why not just make it a special case:


( ) == tuple
(a) == parenthesized expression
(a,b) == tuple
(a,b,c) == tuple
(a,b,c,d) == tuple

etc.

No ambiguities! Only one special case. I submit this special case is
rare, because who wants to define a function that returns a tuple of 1?
Such will come about from generative programming, but:

(a,b,c)[0]

may be how the generative programming works, and that suggests:

(a,0)[0]

as how a user could generate a tuple of 1. Awkward, sure, but like I
said, I think this would be rare.


Sorry for being Debbie Downer in this thread, but I'm not seeing a lot 
of progress here. This is nothing but a syntax cutesy that helps 
Tuple!(A, B) and tuple(a, b) and leaves all other issues related to 
tuples unresolved (I'm actually afraid that it exacerbates them).


One good thing about Tuple is that it allows names of fields, so 
functions can return tuples with conveniently named fields, e.g. 
Tuple!(bool, "found", size_t, "position") etc. without having to define 
little structs everywhere and fostering simple, clear code on the caller 
side.


Also, obviously, empty tuples and tuples with one element are 
self-explanatory (Tuple!() and Tuple!(int) for types, tuple() and 
tuple(4) for values).


Up until recently the syntax t[i] didn't work for tuples, forcing 
t.field[i]. This marginally improves usage of tuples. There are still 
other issues left due to compiler bugs; for example slicing t[a .. b] is 
supposed to work but it doesn't. But my question is, do we need more 
notation, more special cases, more ambiguities, more solution to 
ambiguities, more corner cases (there's already a request for handling 
void in a particular way)...? And for what? Quite literally because we 
refuse to call a tuple a tuple? I'm not seeing much gain here. Syntactic 
sugar is good in moderate quantities, but in Perlis' words this is bound 
to cause cancer of the semicolon.


My suggestion on improving tuples is to fix the compiler bugs that 
currently hamstrung Tuple and to make it the best it can be. Once we're 
clear on the functionality, it would be great to see how we can package 
it better with a bit of language support.



Andrei

Re: Tuple assignment

[Andrei Alexandrescu]

On 10/7/10 1:43 CDT, Russel Winder wrote:

On Wed, 2010-10-06 at 23:08 -0700, Walter Bright wrote:

If expr represents a tuple, we (Andrei and I) were thinking about the syntax:

  auto (a, b, c, d) = expr;

being equivalent to:

  auto t = expr; auto a = t[0]; auto b = t[1]; auto c = t[2 .. $];

You can also do this with arrays, such that:

  float[3] xyz;
  auto (x, y, z) = xyz;

The Lithpers among you will notice that this essentially provides a handy
car,cdr shortcut for tuples and arrays:

  auto (car, cdr) = expr;



Python may be the best base to compare things to as tuple assignment has
been in there for years.

Pythons choice is not a car/cdr approach but an exact match approach.


So then we'd have the proposed notation not work with dynamic arrays - 
only with static arrays and tuples.


Andrei

Re: Template params: decl vs instantiation syntax

[Nick Sabalausky]

"Kagamin"  wrote in message 
news:i8jps1$vh...@digitalmars.com...
> Nick Sabalausky Wrote:
>
>> Template parameter syntax in C++/C#/etc:
>> Declare: foo
>> Instantiate: foo
>
> I thought, template instantiation in C++ is a little bit more complex like
> template<> class Foo
>

Been awhile since I used C++, so I guess I don't know, but C# does like I 
described above. Ie:

class Foo // Declare template
{}

class Bar
{
   Foo f; // Instantiate template
}

It's the same basic syntax either way: "xxx"

> If you instantiate a template explicitly, how do you differentiate between 
> declaration and instantiation?

Not sure what you mean here. Can you provide an example? 

Re: Is D right for me?

[Jacob Carlborg]

On 2010-10-06 14:24, Simen kjaeraas wrote:

Jacob Carlborg  wrote:


Well that's the problem, fixing those bugs and you will encounter new
bugs.


So we should all just give up, then?

Yes, there are bugs, and yes, fixing them will reveal new ones. But the
only reasonable thing to do is to try and fix those bugs that cause the
most headaches, and continue doing so.


I just think it has been show several times that D2 is not ready to be 
used just yet.


--
/Jacob Carlborg

Re: Big executable?

[Jacob Carlborg]

On 2010-10-06 20:01, Walter Bright wrote:

so wrote:

On Wed, 06 Oct 2010 10:40:11 +0300, Jacob Carlborg  wrote:

You are aware of that C is (almost always) dynamically linked with
the standard and runtime library but D (usually) is not? Using D1 and
Tango on Mac OS X (which supports dynamic linking of the standard
library) gives an executable of the size 16 KB if I recall correctly.



Which is the next thing Walter will be working on after this 64bit
business.


Yes, making Phobos a shared library rather than statically linking it
will pretty much resolve this problem.


Of course when Phobos is a dynamic library you would probably need to 
distributed it as well and then you will have same size again or even 
larger.


--
/Jacob Carlborg

Re: Is D right for me?

[Jacob Carlborg]

On 2010-10-06 20:50, Anders F Björklund wrote:

DWT would be better, in that case:
http://wxd.sourceforge.net/#dwt

--anders


Since SWT 3.4 (currently stable version is 3.6) there has been a Cocoa 
port available. DWT is a port of the Cocoa version.


--
/Jacob Carlborg

Re: Is D right for me?

[Jacob Carlborg]

On 2010-10-06 20:53, Gour D. wrote:

On Wed, 06 Oct 2010 20:35:57 +0400

"Denis" == "Denis Koroskin" wrote:


Denis>  Did you try DWT2? http://hg.dsource.org/projects/dwt2

No, but 'doob' on #dwt (it seems this is Jacob Carlborg) replied my
question: "hi, is dwt available for d2?" with "no, not currently", so
I bet I saved some time trying it for myself.


Sincerely,
Gour


Exactly, hopefully I can get DWT to work with D2.


--
/Jacob Carlborg

Re: What would you rewrite in D?

[Jacob Carlborg]

On 2010-10-07 07:00, Nick Sabalausky wrote:

"Gour D."  wrote in message
news:20101007055846.597a5...@atmarama.noip.me...

Although I'm still hankering to see QtD, I'm just curious (not having
experience with) how does SWT (DWT) can compare in regards?


SWT/DWT uses the native GUI, at least on windows. I have no idea what it
uses on Linux, my guess would be GTK-only, but that's only a guess. But I
think DWT is D1-only right now (so is wxD).


It uses native controls on all supported platforms. If there isn't a 
native control available it will emulate it. On Linux GTK and Motif is 
supported, I think they're working on a Qt port as well.


--
/Jacob Carlborg

Re: What would you rewrite in D?

[Jacob Carlborg]

On 2010-10-07 00:26, Robert Clipsham wrote:

On 06/10/10 23:03, Nick Sabalausky wrote:

Ok, for me GTK is native because I use Linux and a GTK based desktop.
I know that there's a native GTK port for OSX/Quartz and I thought
GTK had
themes to look native on Windows?



It does make a vague attempt to look native on Windows, and is FAR
better in
that regard than, say, Swing, Winamp, Iron/Chrome, or pretty much
anything
from Apple. But there's still rather noticable differences in both
look (the
chunkiness I mentioned, just as one example) and in feel (particulary if
you're using GIMP). It's kinda like gluing a picture of some wings
overtop
the logo on a Ferrari and saying "See, it's an Aston Martin!"


Platform wise, GTK looks appalling on OS X, acceptable, if non-native on
Windows (I think there's a GTK theme that fixes this, not sure), and,
well, you use it on linux. As for Qt, it uses the native GUI for all the
platforms it works on (and if you don't like that there's a config tool
to make it look as ugly as you like :)).


I haven't seen any native looking Qt application on Mac.


 From a developers standpoint, GTK is a lot more awkward to work with
(whether you're using the C interface or the GtkD wrapper), and is
generally not as nice to work with (based on a few hundred lines of code
that did very little, I switched to Qt at that point). Qt on the other
hand I've found a pleasure to work with from day 1, everything seems to
work as expected, and typically needs far less code.




--
/Jacob Carlborg

Re: What would you rewrite in D?

[Jacob Carlborg]

On 2010-10-07 08:37, Jonathan M Davis wrote:

On Wednesday 06 October 2010 22:00:02 Nick Sabalausky wrote:

"Gour D."  wrote in message
news:20101007055846.597a5...@atmarama.noip.me...


Although I'm still hankering to see QtD, I'm just curious (not having
experience with) how does SWT (DWT) can compare in regards?


SWT/DWT uses the native GUI, at least on windows. I have no idea what it
uses on Linux, my guess would be GTK-only, but that's only a guess. But I
think DWT is D1-only right now (so is wxD).


SWT uses GTK on Linux (unfortunately), so presumably DWT does as well. It's what
Eclipse uses. However, I do believe that you're right and that it's currently
only D1 compatible.


Correct, though I think they're working on Qt port. I'll try to do my 
best to make DWT work with D2.


--
/Jacob Carlborg

Re: Tuple assignment

[Pelle]

On 10/07/2010 09:03 AM, Walter Bright wrote:

Russel Winder wrote:

Python may be the best base to compare things to as tuple assignment has
been in there for years.


Too segue this into the previous thread, how does Python treat (1)? Is
it a floor wax or a dessert topping?

http://www.nbc.com/saturday-night-live/video/shimmer-floor-wax/1056743/


(1) == 1
(1,) == tuple([1])

Re: Tuple assignment

[Pelle]

On 10/07/2010 08:08 AM, Walter Bright wrote:

If expr represents a tuple, we (Andrei and I) were thinking about the
syntax:

auto (a, b, c, d) = expr;

being equivalent to:

auto t = expr; auto a = t[0]; auto b = t[1]; auto c = t[2 .. $];

You can also do this with arrays, such that:

float[3] xyz;
auto (x, y, z) = xyz;

The Lithpers among you will notice that this essentially provides a
handy car,cdr shortcut for tuples and arrays:

auto (car, cdr) = expr;


Python 3 uses:
car, *cdr = expr
a, *b, c = [1,2,3,4,5] # leaves a=1, b=[2,3,4], c=5

I would like D to have
(car, cdr...) = expr
(a, b..., c) = [1,2,3,4,5]

for the equivalent.

Our varargs syntax is b..., theirs is *b. So it mirrors a bit, there. :-)

Re: Big executable?

[so]

On Thu, 07 Oct 2010 11:39:41 +0300, Jacob Carlborg  wrote:


On 2010-10-06 20:01, Walter Bright wrote:

so wrote:

On Wed, 06 Oct 2010 10:40:11 +0300, Jacob Carlborg  wrote:

You are aware of that C is (almost always) dynamically linked with
the standard and runtime library but D (usually) is not? Using D1 and
Tango on Mac OS X (which supports dynamic linking of the standard
library) gives an executable of the size 16 KB if I recall correctly.



Which is the next thing Walter will be working on after this 64bit
business.


Yes, making Phobos a shared library rather than statically linking it
will pretty much resolve this problem.


Of course when Phobos is a dynamic library you would probably need to  
distributed it as well and then you will have same size again or even  
larger.




Eh?

--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

Re: On C/C++ undefined behaviours (on the term "undefined behaviours")

[Bruno Medeiros]

On 06/10/2010 16:59, Stanislav Blinov wrote:

06.10.2010 19:34, Bruno Medeiros пишет:

On 20/08/2010 17:38, bearophile wrote:

Three good blog posts about undefined behaviour in C and C++:
http://blog.regehr.org/archives/213
http://blog.regehr.org/archives/226
http://blog.regehr.org/archives/232

In those posts (and elsewhere) the expert author gives several good
bites to the ass of most compiler writers.

Among other things in those three posts he talks about two programs as:

import std.c.stdio: printf;
void main() {
printf("%d\n", -int.min);
}

import std.stdio: writeln;
void main() {
enum int N = (1L).sizeof * 8;
auto max = (1L<< (N - 1)) - 1;
writeln(max);
}

I believe that D can't be considered a step forward in system
language programming until it gives a much more serious consideration
for integer-related overflows (and integer-related undefined behaviour).

The good thing is that Java is a living example that even if you
remove most integer-related undefined behaviours your Java code is
still able to run as fast as C and sometimes faster (on normal
desktops).

Bye,
bearophile


Interesting post.

There is a important related issue here. It should be noted that, even
though the article and the C FAQ say:
"
The C FAQ defines “undefined behavior” like this:

Anything at all can happen; the Standard imposes no requirements. The
program may fail to compile, or it may execute incorrectly (either
crashing or silently generating incorrect results), or it may
fortuitously do exactly what the programmer intended.
"
this definition of "undefined behavior" is not used consistently by C
programmers, or even by more official sources such as books, or even
the C standards. A trivial example:

foo(printf("Hello"), printf("World"));

Since the evaluation order of arguments in not defined in C, these two
printfs can be executed in any of the two possible orders. The
behavior is not specified, it is up to the implementation, to the
compiler switches, etc..
Many C programmers would say that such code has/is/produces undefined
behavior, however, that is clearly not “undefined behavior” as per the
definition above. A correct compiler cannot cause the code above to
execute incorrectly, crash, calculate PI, format you hard disk,
whatever, like on the other cases. It has to do everything it is
supposed to do, and the only "undefined" thing is the order of
evaluation, but the code is not "invalid".

I don't like this term "undefined behavior". It is an unfortunate C
legacy that leads to unnecessary confusion and misunderstanding, not
just in conversation, but often in coding as well. It would not be so
bad if the programmers had the distinction clear at least in their
minds, or in the context of their discussion. But that is often not
the case.

I've called before for this term to be avoided in D vocabulary, mainly
because Walter often (ab)used the term as per the usual C legacy.
The “undefined behavior” as per the C FAQ should be called something
else, like "invalid behavior". Code that when given valid inputs
causes invalid behavior should be called invalid code.
(BTW, this maps directly to the concept of contract violations.)



I always thought that the term itself came from language specification,
i.e. the paper that *defines* behavior of the language and states that
there are cases when behavior is not defined (i.e. in terms of the
specification). From this point of view the term is understandable and,
uh, valid. It's just that it got abused with time, especially this abuse
is notable in discussions (e.g. "Don't do that, undefined behavior will
result": one can sit and guess how exactly she will get something that
is not defined).



"the term itself came from language specification" -> yes that is 
correct. I read K&R's "The C Programming Language", second edition, and 
the term comes from there, at least as applied to C. But they don't 
define or use the term as the C FAQ above, or at least not as 
explicitly, if I recall correctly (im 98% sure I am). They just describe 
each particular language rule individually and tell you what to expect 
if you break the rule. Often they will say something like "this will 
cause undefined behavior" and it is clear that is is illegal. But other 
times they would say something like "X is undefined", where X could be 
"the order of execution", "the results of Y", "the contents of variable 
Z", and it is not clear whether that meant the program could exhibit 
undefined behavior or not. (or in other words if that was illegal or not)


I don't know if this concept or related ones have actually been better 
formalized in newer revisions of the C standard.



I don't think that "invalid behavior" covers that sense: it means that
implementation should actually do something to make code perform
'invalid' things (what should be considered invalid, by the way?),
rather than have the possibility to best adapt the behavior to system
(e.g. segfault) or some error handling mechanism (e.g. thr

Re: Tuple literal syntax

[retard]

Thu, 07 Oct 2010 03:20:23 -0500, Andrei Alexandrescu wrote:

> Sorry for being Debbie Downer in this thread, but I'm not seeing a lot
> of progress here. This is nothing but a syntax cutesy that helps
> Tuple!(A, B) and tuple(a, b) and leaves all other issues related to
> tuples unresolved (I'm actually afraid that it exacerbates them).
> 
> One good thing about Tuple is that it allows names of fields, so
> functions can return tuples with conveniently named fields, e.g.
> Tuple!(bool, "found", size_t, "position") etc. without having to define
> little structs everywhere and fostering simple, clear code on the caller
> side.

Why do tuple fields need a name? Isn't this a new ad-hoc way to introduce 
structural typing in D? I often start with tuples, but if it turns out 
that the value is used in many places, it will be eventually replaced 
with a struct (e.g. coordinates in a gui / gamedev) for better type 
safety. Even with structs the need for field names is very rare. The real 
need for tuples is in very special cases where the syntax needs to be 
light.

Re: Big executable?

[retard]

Thu, 07 Oct 2010 13:27:23 +0300, so wrote:

> On Thu, 07 Oct 2010 11:39:41 +0300, Jacob Carlborg  wrote:
> 
>> On 2010-10-06 20:01, Walter Bright wrote:
>>> so wrote:
 On Wed, 06 Oct 2010 10:40:11 +0300, Jacob Carlborg 
 wrote:
> You are aware of that C is (almost always) dynamically linked with
> the standard and runtime library but D (usually) is not? Using D1
> and Tango on Mac OS X (which supports dynamic linking of the
> standard library) gives an executable of the size 16 KB if I recall
> correctly.
>
>
 Which is the next thing Walter will be working on after this 64bit
 business.
>>>
>>> Yes, making Phobos a shared library rather than statically linking it
>>> will pretty much resolve this problem.
>>
>> Of course when Phobos is a dynamic library you would probably need to
>> distributed it as well and then you will have same size again or even
>> larger.
>>
>>
> Eh?

If the DMD/Phobos distribution doesn't provide compatible API/ABI between 
DMD/Phobos versions, the dynamic library has very little use since all 
libraries need to be distributed with the 3rd party application.

Re: About Andrei's interview, part 3 (on bearophile)

[Bruno Medeiros]

On 06/10/2010 22:47, Juanjo Alvarez wrote:

On Wed, 06 Oct 2010 16:55:40 +0100, Bruno Medeiros
 wrote:

Reading newsgroups on phone would suck. I already get a bit
uncomfortable reading them on my laptop (without a peripheral

monitor or

mouse).


Not worse than reading email on a phone,trough the experience is course
worse than on a computer.


Oh, it is indeed worse that reading email on a phone, unless you also 
use your email to have huge threaded discussions. Doesn't matter for me 
in any case, as I also don't read email on a phone.


--
Bruno Medeiros - Software Engineer

Re: Is D right for me?

[Anders F Björklund]

Jacob Carlborg wrote:

DWT would be better, in that case:
http://wxd.sourceforge.net/#dwt

Since SWT 3.4 (currently stable version is 3.6) there has been a Cocoa 
port available. DWT is a port of the Cocoa version.




Yeah, that page is a bit outdated. But I'll try to fix.

When it was first written, it was Phobos and Carbon :-)

--anders

Re: Big executable?

[so]

On Thu, 07 Oct 2010 13:41:26 +0300, retard  wrote:


Thu, 07 Oct 2010 13:27:23 +0300, so wrote:


On Thu, 07 Oct 2010 11:39:41 +0300, Jacob Carlborg  wrote:


On 2010-10-06 20:01, Walter Bright wrote:

so wrote:

On Wed, 06 Oct 2010 10:40:11 +0300, Jacob Carlborg 
wrote:

You are aware of that C is (almost always) dynamically linked with
the standard and runtime library but D (usually) is not? Using D1
and Tango on Mac OS X (which supports dynamic linking of the
standard library) gives an executable of the size 16 KB if I recall
correctly.



Which is the next thing Walter will be working on after this 64bit
business.


Yes, making Phobos a shared library rather than statically linking it
will pretty much resolve this problem.


Of course when Phobos is a dynamic library you would probably need to
distributed it as well and then you will have same size again or even
larger.



Eh?


If the DMD/Phobos distribution doesn't provide compatible API/ABI between
DMD/Phobos versions, the dynamic library has very little use since all
libraries need to be distributed with the 3rd party application.


If we want to distribute a single shared library, until things get settled  
there is nothing we can do.
Also we are not talking about a single exec per project right? If this is  
what you mean, yes i agree it has no use,
but if in your project you got more than one executable or shared library  
it is a gain.


We all know how shared libraries work right?

--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

Re: Template params: decl vs instantiation syntax

[Daniel Gibson]

Nick Sabalausky schrieb:

A trivial thing, but something I've been wondering about for awhile:

Function parameter syntax:
Declare: foo(bar)
Call: foo(bar)

Template parameter syntax in C++/C#/etc:
Declare: foo
Instantiate: foo

Template parameter syntax in D:
Declare: foo(bar)
Instantiate: foo!(bar)

Why the difference in syntax between declaring and instantiating? Why not 
use the exclamation for declaration too? Would that create a grammar 
ambiguity? Some other reason? No particular reason?


Obviously it's not a big issue, just curious.




because:

import std.stdio;

void fun(int X=3)(int a = 4){
writefln("X==%s a==%s", X, a);
}

void main() {
fun!(1)(2); // X==1, a==2
fun(2); // X==3, a==2
fun!(2); // X==2, a==4
}


Cheers,
- Daniel

Re: On C/C++ undefined behaviours (on the term "undefined behaviours")

[Stanislav Blinov]

 07.10.2010 14:38, Bruno Medeiros wrote:

On 06/10/2010 16:59, Stanislav Blinov wrote:


I always thought that the term itself came from language specification,
i.e. the paper that *defines* behavior of the language and states that
there are cases when behavior is not defined (i.e. in terms of the
specification). From this point of view the term is understandable and,
uh, valid. It's just that it got abused with time, especially this abuse
is notable in discussions (e.g. "Don't do that, undefined behavior will
result": one can sit and guess how exactly she will get something that
is not defined).



"the term itself came from language specification" -> yes that is 
correct. I read K&R's "The C Programming Language", second edition, 
and the term comes from there, at least as applied to C. But they 
don't define or use the term as the C FAQ above, or at least not as 
explicitly, if I recall correctly (im 98% sure I am). 
Now, I'm not on a solid grounds to argue (being not a native English 
speaker), but the need to actually define this term seems dubious to me, 
kind of another abuse if you please. The term means just exactly what it 
says: the behavior [of the code/program/compiler/system/you_name_it] is 
not defined, i.e. no restrictions or rules are attached to it. To me, 
attempts to define undefined seem like attempts on 'adding one briefcase 
into another' (from Win98 days).
They just describe each particular language rule individually and tell 
you what to expect if you break the rule. Often they will say 
something like "this will cause undefined behavior" and it is clear 
that is is illegal. 
Strictly speaking, it's not 'illegal'. If we talk about C (and we do ;) 
), being a systems language, it cannot demand strict ways of handling 
every situation from an implementation. Some systems may choke on 
integer overflow, some may not. Some build made with single compiler may 
get you useful data when addressing seemingly out-of-bounds data, yet 
some builds (made with the same compiler) would grant you access 
violation. (i.e. debug/release builds of MSVC).
Stating that behavior in some case is not defined, the spec leaves 
implementation with a possibility to best handle that case (or, of 
course, not handle it at all), or at least adapt it to some use (e.g. 
for debugging), which is great for systems language, because many such 
'undefined' cases can be handled very differently (in terms of 
results/efficiency/whatnot) on different systems. Of course, it does not 
imply that writing code that behaves in an 'undefined' manner is a good 
thing to do, but being strict with what a compiler should do in all 
cases is neither. Of course, replacing 'undefined behavior' with 
'implementation-specific behavior' would look better, but that again 
puts forward a demand (restriction) rather than possibility.
But other times they would say something like "X is undefined", where 
X could be "the order of execution", "the results of Y", "the contents 
of variable Z", and it is not clear whether that meant the program 
could exhibit undefined behavior or not. (or in other words if that 
was illegal or not)


Well, this ambiguity is hardly relating to a programming language, but 
rather to natural one.
I don't know if this concept or related ones have actually been better 
formalized in newer revisions of the C standard.



I don't think that "invalid behavior" covers that sense: it means that
implementation should actually do something to make code perform
'invalid' things (what should be considered invalid, by the way?),
rather than have the possibility to best adapt the behavior to system
(e.g. segfault) or some error handling mechanism (e.g. throw an 
exception).


In this case I don't know for sure what the best alternative term is, 
I just want to avoid confusion with "invalid behavior". I want to know 
when a program execution may actually be invalidated (crash, memory 
corruption, etc.), versus when it is just some particular and 
*isolated* aspect of behavior that is simply "undefined", but program 
execution is not invalidated. In other words, if it is illegal or not.

Re: Big executable?

[Kagamin]

so Wrote:

> > 300kb is the lower limit if you use phobos and druntime.
> 
> First response (and yet not actually an answer) to a newcomer is from a  
> phobos hater, isn't it grand!

In fact, I don't see a problem in 300kb exe size. This time I didn't have hate 
in mind, I just checked my executables' size and figured out the answer. I 
don't know, what is responsible for this big size, though it doesn't seem to be 
C runtime.

"in" everywhere

[atommixz]

It would be nice if it were possible to use the "in" expression wherever
possible. Now it is only implemented for associative. arrays. (Weird).
Examples of how this could be used:
- Find string in string
- Search for a character in a string
- Search for an item in the array, array of characters, array of strings,
tuples, enum, structure
- what else?

In Python done something like this.

Here it would be useful to me
http://code.google.com/p/atommixz/source/browse/analyze-x86/analyze-x86.py
http://code.google.com/p/atommixz/source/browse/analyze-x86/analyzex86.d

Re: Tuple literal syntax

[Kagamin]

retard Wrote:

> safety. Even with structs the need for field names is very rare. The real 
> need for tuples is in very special cases where the syntax needs to be 
> light.

You really need tuples to write obscure functional code.

Re: Tuple literal syntax + Tuple assignment

[bearophile]

In the two threads (that are a single thread) most of the things I've seen are 
bad/wrong.

I have discussed about Tuples several times in the D newsgroup and in Bugzilla. 
Please don't ignore all my work.

Before designing tuple syntax you must decide what the purpose of D tuples is. 
Then you have to solve the design problems, and avoid all (or most) corner 
cases. In this discussion it's useful to have a certain experience of languages 
that use tuples often, as Python and others.

Tuples have some purposes:
- Python, Go and other languages show that it's handy to allow functions to 
return multiple values, this means a tuple.
- A handy tuple unpacking is useful at the calling point of a function that 
returns multiple return values.
- Tuples are also useful as quick-and-dirty structs, to sort items in a 
different order, etc.

It's useful to use [] to access tuple items, to slice tuples, concat them. It's 
useful for tuples to have a good textual representation, to be comparable 
lexicographically and to be hashable.

Another design decision is if tuples have a nominative or structural type, this 
problem comes out in this bug report:
http://d.puremagic.com/issues/show_bug.cgi?id=4128

In my opinion it's good for a built-in D tuple to be a structural type. This 
also means you are allowed to perform an == among two tuples of different 
length (the result is known statically to be always false). I assume that D 
tuples know their length at compile-time.


Another significant problem is about naming things, currently the situation is 
a mess:
http://www.digitalmars.com/d/archives/digitalmars/D/Tuple_TypeTuple_tupleof_etc_113005.html
http://d.puremagic.com/issues/show_bug.cgi?id=4113
In the end I have suggested to name "record" the typecons tuples, and "tuple" 
the typetuples.


I have several bug reports and enhancement requests about tuples, please take 
them into account:

http://d.puremagic.com/issues/show_bug.cgi?id=4577
http://d.puremagic.com/issues/show_bug.cgi?id=4582
http://d.puremagic.com/issues/show_bug.cgi?id=4591
http://d.puremagic.com/issues/show_bug.cgi?id=4666
http://d.puremagic.com/issues/show_bug.cgi?id=4846


Walter:

> A lot of it foundered on what the syntax for tuple literals should be. The top
> of the list is simply enclosing them in ( ).

This is a bad idea. It has caused troubles in Python because of the singleton 
syntax (tuple with 1 item).

One solution is to use a special unambigous delimiter to denote tuples, like (a 
similar solution is used in the Fortress language):

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


Otherwise a good solution is to use a name:

record()
record(1)
record(1, 2)
record(1, 2, 3)
record(1, 2, 3, 4)

I prefer the record() solution, but the first solution too acceptable.


> Finally, I got to thinking, why not just make it a special case:
> 
>   ( ) == tuple
>   (a) == parenthesized expression

This is not acceptable. No special cases, please. D has already a ton of 
special cases.
Python solves this with the (1,) syntax, but it's not nice, it's error-prone, 
and it confuses newbies.


> If expr represents a tuple, we (Andrei and I) were thinking about the syntax:
> 
>  auto (a, b, c, d) = expr;

On this topic I have this enhancement request:
http://d.puremagic.com/issues/show_bug.cgi?id=4579


> The Lithpers among you will notice that this essentially provides a handy
> car,cdr shortcut for tuples and arrays:
> 
>  auto (car, cdr) = expr;

This is bad, it's not explicit enough. If you want to support this semantics 
then the syntax has to show what you mean. Python uses a * to denote "grab the 
whole tail". In D you may use something else, others have suggested tree 
points, this works with dynamic arrays too:

auto (car, cdr...) = expr;


Regarding field names for tuples, I have used Python and I like the optional 
names of D tuples (records). In some situations you don't need names, but in 
other situations field names are handy and help avoid bugs. In Python code that 
processes and uses tuples contains too many [0] [1] [2] etc that aren't 
readable and are bug-prone.

But a good management of such names asks for the names to not change the type 
of the tuple, this is why I talk about structural typing for records.

Bye,
bearophile

Re: About Andrei's interview, part 3 (on bearophile)

[Juanjo Alvarez]

Bruno Medeiros Wrote:

> On 06/10/2010 22:47, Juanjo Alvarez wrote:
> > On Wed, 06 Oct 2010 16:55:40 +0100, Bruno Medeiros
> >  wrote:
> >> Reading newsgroups on phone would suck. I already get a bit
> >> uncomfortable reading them on my laptop (without a peripheral
> > monitor or
> >> mouse).
> >
> > Not worse than reading email on a phone,trough the experience is course
> > worse than on a computer.
> 
> Oh, it is indeed worse that reading email on a phone, unless you also 
> use your email to have huge threaded discussions. Doesn't matter for me 
> in any case, as I also don't read email on a phone.

On my app you see the threaded messages in a screen and then when you tap or 
select a message its opened in another view, fullscreen. Go back and you are 
again in the threaded listing (which the read messages greyed), or tap Next and 
you go to the next message in the tree without existing the message view.

As I said, not the same level of conveniente than on a computer (you can't see 
the thread and the message at the same time), but still not so bad.

Re: Template params: decl vs instantiation syntax

[Kagamin]

Nick Sabalausky Wrote:

> > I thought, template instantiation in C++ is a little bit more complex like
> > template<> class Foo
> >
> 
> Been awhile since I used C++, so I guess I don't know, but C# does like I 
> described above. Ie:
> 
> class Foo // Declare template
> {}
> 
> class Bar
> {
>Foo f; // Instantiate template
> }
> 
> It's the same basic syntax either way: "xxx"
> 
> > If you instantiate a template explicitly, how do you differentiate between 
> > declaration and instantiation?
> 
> Not sure what you mean here. Can you provide an example? 
> 
Aah, it's called Explicit Specialization. See factorial implementation at 
http://digitalmars.com/d/2.0/template-comparison.html

Re: Tuple assignment

[Juanjo Alvarez]

Denis Koroskin Wrote:


> That's because Python is not a strictly typed language. With proper type  
> propagation compiler helps you writing code the way in meant to be. E.g.  
> the following:
> 
> (a, b, c, d) = ('tuple', 'of', 'three')
> 
> could be statically disabled, but there is nothing wrong with allowing it  
> either: d would be just a no-op, you will know it for sure the moment you  
> try using it.

Python has the special symbol "_" which is used exactly as a no-op (you could 
call it "foo" it you wanted, but "_" 
doesn't create new memory assignments) so you can expand arbitrary tuples 
without creating new symbols:

a, b, c, _ = ('tuple', 'of', 'three')

I like the proposal for D, but I fear it could be a source of bugs (you expect 
the tuple to expand to 4 values
 but silently is expanding to only 3, leaving the fourth unchangued).

Re: Big executable?

[retard]

Thu, 07 Oct 2010 14:08:17 +0300, so wrote:

> On Thu, 07 Oct 2010 13:41:26 +0300, retard  wrote:
> 
>> Thu, 07 Oct 2010 13:27:23 +0300, so wrote:
>>
>>> On Thu, 07 Oct 2010 11:39:41 +0300, Jacob Carlborg 
>>> wrote:
>>>
 On 2010-10-06 20:01, Walter Bright wrote:
> so wrote:
>> On Wed, 06 Oct 2010 10:40:11 +0300, Jacob Carlborg 
>> wrote:
>>> You are aware of that C is (almost always) dynamically linked with
>>> the standard and runtime library but D (usually) is not? Using D1
>>> and Tango on Mac OS X (which supports dynamic linking of the
>>> standard library) gives an executable of the size 16 KB if I
>>> recall correctly.
>>>
>>>
>> Which is the next thing Walter will be working on after this 64bit
>> business.
>
> Yes, making Phobos a shared library rather than statically linking
> it will pretty much resolve this problem.

 Of course when Phobos is a dynamic library you would probably need to
 distributed it as well and then you will have same size again or even
 larger.


>>> Eh?
>>
>> If the DMD/Phobos distribution doesn't provide compatible API/ABI
>> between DMD/Phobos versions, the dynamic library has very little use
>> since all libraries need to be distributed with the 3rd party
>> application.
> 
> If we want to distribute a single shared library, until things get
> settled there is nothing we can do.
> Also we are not talking about a single exec per project right? If this
> is what you mean, yes i agree it has no use, but if in your project you
> got more than one executable or shared library it is a gain.

Yes, that's a fair point.

> 
> We all know how shared libraries work right?

Sorry for that. The answer was directed more towards the original poster. 

Re: Tuple literal syntax

[Juanjo Alvarez]

retard Wrote:


> Why do tuple fields need a name? Isn't this a new ad-hoc way to introduce 
> structural typing in D? I often start with tuples, but if it turns out 
> that the value is used in many places, it will be eventually replaced 
> with a struct (e.g. coordinates in a gui / gamedev) for better type 
> safety. Even with structs the need for field names is very rare. The real 
> need for tuples is in very special cases where the syntax needs to be 
> light.

I found they are useful for callbacks, when you can put, in a tuple, the 
delegate or function to the callback
 and in another nested tuple the delegate/function parameters.

This way you can define the callbacks to be used along with their parameters, 
even if their signature is different.

You could do the same with the callbacks having variable number and types of 
args, using a template, but I like 
this way more.

Re: Tuple literal syntax

[Justin Johansson]

On 7/10/2010 5:04 PM, Walter Bright wrote:

There have been a couple of looong threads about tuples:

http://www.digitalmars.com/d/archives/digitalmars/D/Reddit_why_aren_t_people_using_D_93528.html

http://www.digitalmars.com/d/archives/digitalmars/D/Should_the_comma_operator_be_removed_in_D2_101321.html

A lot of it foundered on what the syntax for tuple literals should be.
The top of the list is simply enclosing them in ( ). The problem with
this is


Walter, please define exactly what a tuple is as being, both
in the context of your post and (presumably) in the D type system.

Without a precise definition of exactly what a tuple is,
your post will at best elucidate responses that also lack a
precise understanding of a tuple is (supposed to be).

There are already a number of responses to your post that focus
on syntax and without any semantic foundation.

Regards,
Justin Johansson

Re: Ruling out arbitrary cost copy construction?

[Michel Fortin]

On 2010-10-07 02:09:04 -0400, Andrei Alexandrescu 
 said:


I agree with all of the above. After all has been said and done, it 
looks like uniform function call syntax is a pivotal feature for 
simplifying ranges. Most ranges can simply define the basic operations, 
and std.range takes care of defining boilerplate defaults for a host of 
cases. For example, you just call r.moveFront() and that becomes 
moveFront(r) which is defined by std.range.


That's good. I'm glad to see that using move semantics is still on the table.

Another note, you don't really need to wait for the uniform function 
call syntax for this to work. The moveFront function template in 
std.range could check for the presence of moveFront in the range and 
call it when available. This means you have to write moveFront(r) 
everywhere instead of r.moveFront(), which might be an annoyance but at 
least it works.



Whenever the range is defined in a way that makes it impossible to 
generate e.g. moveFront() appropriately, the user would have to. Would 
this be acceptable?


Seems good to me.


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

Re: Template params: decl vs instantiation syntax

[Nick Sabalausky]

"Daniel Gibson"  wrote in message 
news:i8kakj$230...@digitalmars.com...
> Nick Sabalausky schrieb:
>> A trivial thing, but something I've been wondering about for awhile:
>>
>> Function parameter syntax:
>> Declare: foo(bar)
>> Call: foo(bar)
>>
>> Template parameter syntax in C++/C#/etc:
>> Declare: foo
>> Instantiate: foo
>>
>> Template parameter syntax in D:
>> Declare: foo(bar)
>> Instantiate: foo!(bar)
>>
>> Why the difference in syntax between declaring and instantiating? Why not 
>> use the exclamation for declaration too? Would that create a grammar 
>> ambiguity? Some other reason? No particular reason?
>>
>> Obviously it's not a big issue, just curious.
>>
>>
>
> because:
>
> import std.stdio;
>
> void fun(int X=3)(int a = 4){
> writefln("X==%s a==%s", X, a);
> }
>
> void main() {
> fun!(1)(2); // X==1, a==2
> fun(2); // X==3, a==2
> fun!(2); // X==2, a==4
> }
>
>

I think you misunderstood the question. I understand why there's a 
difference between function parameter syntax and template parameter syntax. 
What I don't understand is why there's a difference between the syntaxes for 
template instantiations and template declarations. Ie, why isn't D designed 
so that your 'fun' function above is like this?:

// Note the "!":
void fun!(int X=3)(int a = 4)
{...}

Or why class templates aren't like this?:

class Foo!(T) {}

For ordinary functions, you call *and* define using "()".  In certain non-D 
langauges, templates/generics are instantiated *and* defined using "<>". In 
D, templates are instantiated with "!()", but they're defined with "()". I'm 
wondering why they're not instantiated *and* defined using "!()".

Re: Big executable?

[Justin Johansson]

On 6/10/2010 5:12 PM, Andre Tampubolon wrote:

Hi,

I just started learning D (my background is C, anyway).

I compiled this simple code using DMD 2.049 (dmd -O -release test1.d) :
import std.stdio;

void main()
{
writefln("%s World", "Hello");
}

The final executable size is about 300 KB. Isn't that a bit huge,
considering the same code compiled using C or Pascal compiler will give
smaller executable? So I tried to look at the *.map, and apparently the
D runtime pulls a lot of stuff. I am just wondering, anyway.


Try assembly language.  Your executable will be less than 256 bytes
(perhaps on legacy operating systems, and, of course, using the
O/S to make a call to write to stdout).

Naturally YMMV depending on the language translator that you use,
and, as you have appropriately noted, your mileage experience is
not climate-change friendly.

-- Justin

Re: Template params: decl vs instantiation syntax

[Daniel Gibson]

Nick Sabalausky schrieb:
"Daniel Gibson"  wrote in message 
news:i8kakj$230...@digitalmars.com...

Nick Sabalausky schrieb:

A trivial thing, but something I've been wondering about for awhile:

Function parameter syntax:
Declare: foo(bar)
Call: foo(bar)

Template parameter syntax in C++/C#/etc:
Declare: foo
Instantiate: foo

Template parameter syntax in D:
Declare: foo(bar)
Instantiate: foo!(bar)

Why the difference in syntax between declaring and instantiating? Why not 
use the exclamation for declaration too? Would that create a grammar 
ambiguity? Some other reason? No particular reason?


Obviously it's not a big issue, just curious.



because:

import std.stdio;

void fun(int X=3)(int a = 4){
writefln("X==%s a==%s", X, a);
}

void main() {
fun!(1)(2); // X==1, a==2
fun(2); // X==3, a==2
fun!(2); // X==2, a==4
}




I think you misunderstood the question. I understand why there's a 
difference between function parameter syntax and template parameter syntax. 
What I don't understand is why there's a difference between the syntaxes for 
template instantiations and template declarations. Ie, why isn't D designed 
so that your 'fun' function above is like this?:


// Note the "!":
void fun!(int X=3)(int a = 4)
{...}

Or why class templates aren't like this?:

class Foo!(T) {}

For ordinary functions, you call *and* define using "()".  In certain non-D 
langauges, templates/generics are instantiated *and* defined using "<>". In 
D, templates are instantiated with "!()", but they're defined with "()". I'm 
wondering why they're not instantiated *and* defined using "!()".




Ah ok, I read over "Why not use the exclamation for declaration too?" 
and thought you wanted to eliminate the ! for instantiation. Sorry.

Re: Big executable?

[Juanjo Alvarez]

Justin Johansson Wrote:


> Naturally YMMV depending on the language translator that you use,
> and, as you have appropriately noted, your mileage experience is
> not climate-change friendly.

46 bytes on Linux, using serious hackery; interesting & funny read:

http://www.muppetlabs.com/~breadbox/software/tiny/teensy.html

Re: Ruling out arbitrary cost copy construction?

[Steven Schveighoffer]

On Wed, 06 Oct 2010 19:09:15 -0400, Andrei Alexandrescu  
 wrote:



On 10/6/10 12:50 CDT, Steven Schveighoffer wrote:

I agree all of this except for save() (not a secret to anyone who's read
my posts).


What was your alternative design that obviates save()?


First, let me discuss why I don't like save.

Let's classify ranges into two types.  Primitive ranges are ones that  
provide a range interface to data that otherwise does not have a range  
interface.  A good example is a container range.


Compound ranges are ranges that combine or alter range functionality from  
a wrapped range or set of ranges.  A good example is Zip or Chain.


Let's also define the trivial save implementation as a single line: return  
this;


We can assume that compound ranges don't contain a trivial solution, but  
only because the range(s)  they contain could implement a non-trivial  
solution.  So we can qualify those trivial, even though they don't have  
the canonical trival solution.


Most ranges that are not compound implement the trivial solution.  This  
includes all dcollections ranges and *ALL* non-compound ranges in phobos.


Then there are ranges which cannot implement save whatsoever, even if they  
wanted to.  A range that provides the range interface for a network stream  
would be a good example.


That leaves us with ranges which cannot implement the trival solution, but  
can implement save.  A class-based range would be a good example.   
Currently, there are zero examples of this type of range.  That's right,  
zero (grep 'save()' std/*.d).  I contend that we have no place for such  
ranges in D.


So my question is, what is the point of save?  The whole point is for this  
last class of ranges, so they can implement a way to copy the iteration  
position in a way that isn't doable via simple assignment.  But there  
*AREN'T ANY* of these ranges in existence.  Why do we have a feature that  
is littered all over phobos and any range that wants to be more than a  
basic imput range when the implementation is return this; ?


Now, this isn't quite fair -- save is important not only for what it  
provides but for what it excludes.  It correctly excludes the ranges that  
cannot implement it.  And these types of ranges do exist.  So if we get  
rid of save, we have to compensate for this as well.



So now you know why I don't like save.  I'll move on to my alternative.

My solution is this.  The class of ranges that cannot implement the  
trivial save will define an enum refIterator to be true.  And that's it.   
It shouldn't hurt currently since no ranges implement a non-trivial save.   
If we come across a range where it makes sense to implement save, we can  
figure that out later.  But our solution works easily in phobos:


size_t bringToFront(Range1, Range2)(Range1 front, Range2 back)
if (isForwardRange!Range1 && isForwardRange!Range2)

Look, there's already a template constraint for isForwardRange.  Just  
define isForwardRange to disqualify ranges which define the refIterator  
enum, and we have to change no code (except get rid of all the save  
litter).



I'll also note, another unsolved issue with this is iteration --
iterating a sealed range via foreach is not going to use moveFront.


Well it shouldn't because the user doesn't want to destroy the stuff is  
iterating.


Yeah, but I also don't think by default he wants to make an arbitrary-cost  
copy.


Imagine a situation like this:

foreach(i; arr)
{
   if(i > 5)
 return i;
}

If arr is an array of BigInt, you are copying all of them out of the  
array, just to read them.


All I'm saying is moveFront simply solves the swapping problem, there are  
other problems with arbitrary cost copy construction that are not solved  
by moveFront.



Andrei wrote:

4. It would be a definite departure from C++, where all value copies
are considered of arbitrary cost. This would provide a convenient
straw-man for naysayers (e.g. "Hey, D calls the copy constructor even
more often than C++! No thanks, I'll stick with C++0x which solves it
all with rvalue references").


Wait, shouldn't auto ref solve the rvalue references thing? I mean if
you are copying an rvalue, there is no reason to keep the original
around, so no need to call the copy constructor, right?


auto ref has its uses, but designing an interface with front() but not  
moveFront() will make it impossible to move the front out of the range.


But your point was about how C++ has rvalue references, how does rvalue  
references solve the moveFront problem?  FWIW, I thought C++ supports  
passing rvalue references only by const, no?


-Steve

Re: Tuple literal syntax

[Ellery Newcomer]

I might be missing something, but how does this proposal get around the 
ambiguity in


(a,b,c)[0]

?

Currently, it's valid C syntax and valid D syntax. In your proposal it 
would be valid tuple syntax too.


On 10/07/2010 01:04 AM, Walter Bright wrote:

There have been a couple of looong threads about tuples:

http://www.digitalmars.com/d/archives/digitalmars/D/Reddit_why_aren_t_people_using_D_93528.html


http://www.digitalmars.com/d/archives/digitalmars/D/Should_the_comma_operator_be_removed_in_D2_101321.html


A lot of it foundered on what the syntax for tuple literals should be.
The top of the list is simply enclosing them in ( ). The problem with
this is

(expression)

Is that a parenthesized expression, or a tuple? This really matters,
since (e)[0] means very different things for the two. Finally, I got to
thinking, why not just make it a special case:


( ) == tuple
(a) == parenthesized expression
(a,b) == tuple
(a,b,c) == tuple
(a,b,c,d) == tuple

etc.

No ambiguities! Only one special case. I submit this special case is
rare, because who wants to define a function that returns a tuple of 1?
Such will come about from generative programming, but:

(a,b,c)[0]

may be how the generative programming works, and that suggests:

(a,0)[0]

as how a user could generate a tuple of 1. Awkward, sure, but like I
said, I think this would be rare.

Re: Is D right for me?

[Justin Johansson]

On 7/10/2010 1:35 AM, Andrei Alexandrescu wrote:

On 10/6/10 7:24 CDT, Simen kjaeraas wrote:

Jacob Carlborg  wrote:


Well that's the problem, fixing those bugs and you will encounter new
bugs.


So we should all just give up, then?

Yes, there are bugs, and yes, fixing them will reveal new ones. But the
only reasonable thing to do is to try and fix those bugs that cause the
most headaches, and continue doing so.


I agree that that looked like an unwinnable battle while D was also
evolving rapidly. Now that the language is stabilizing I expect the rate
and the absolute number of bugs will decrease.

Andrei


I think that long are the days that a single individual (or corporation)
can "own" a language.  It will be an unwinnable battle so long as the
governance of D is under the auspices of a single mortal.

There is too much risk for investors of time let alone pecuniary
investors under the current regime.

Justin

Re: Tuple literal syntax

[Justin Johansson]

On 8/10/2010 12:23 AM, Ellery Newcomer wrote:

I might be missing something, but how does this proposal get around the
ambiguity in

(a,b,c)[0]

?

Currently, it's valid C syntax and valid D syntax. In your proposal it
would be valid tuple syntax too.


Sorry Ellery but you, as others, are also focusing on syntax and not
a semantic foundation for what tuples are.  I note that bearophile
makes similar points about the meaning of tuples in a latter post.

Without understanding what the meaning of tuples is and what they
might be good for, it (imho) doesn't make sense to enter into
syntactic arguments.

Justin

Re: Ruling out arbitrary cost copy construction?

[Steven Schveighoffer]

On Wed, 06 Oct 2010 16:19:45 -0400, Andrei Alexandrescu  
 wrote:



On 10/6/10 14:09 CDT, Michel Fortin wrote:

On 2010-10-06 12:34:54 -0400, Andrei Alexandrescu
 said:


2. It would force certain types (such as BigInt) that allocate
resources and have value semantics to resort to reference counting.


Also, before asking for more reference counting, perhaps you should
check that bug and find a nice way to do reference counting correctly
with no race conditions (unlike what's done in Phobos currently).



I'm not sure the bug report is valid, but I agree it's a matter to look  
into.


It is valid.  When you use GC-allocated memory in a destructor, it's bad  
news.  And structs that are members of classes can have their destructors  
called from the GC.



The most problematic thing with reference-counted memory is that the GC
can call your struct's destructor from any thread which can cause
low-level races if the reference counter isn't manipulated with atomic
operations. And atomic operations slow things down, are you sure you
want to force this in BigInt?


The GC shouldn't be able to destroy things naively concurrently with  
other threads. Currently all threads are frozen; I'm not sure whether a  
frozen thread commits its writes, so that needs to be verified.


I think Michel is right.  Let's say thread A is copying a File struct to  
the stack, and is on this line:



this(this)
{
if (!p) return;
assert(p.refs);

  ++p.refs;

}

And thread B is allocating memory.  This triggers a GC collection cycle,  
and in the heap is a class object which contains the same File struct as a  
member.  That File's destructor is called, and
--refs is called.  Note that the object being destroyed does not have to  
be shared. This is a classic race.


-Steve

Re: phobos is failure

[Steven Schveighoffer]

On Wed, 06 Oct 2010 17:51:33 -0400, Nick Sabalausky  wrote:
IMHO, the primary reason for Tango has been eroding (at least for D2).  
As I

always saw it, the whole point of Tango was that Phobos was basically
early-alpha-level with practically no features, and no one actively  
working

on it (just a little bit of occasional attention from Walter). In those
days, Tango mage *perfect* sense. But Phobos2 has come such a long way,  
and

has the added bonus of not leaving you lost in epic package/class
hierarchies. I don't mean to bash Tango, I used it and loved it for a  
long

time. I'm just not sure it's really needed on D2.


As a library, I loved and used Tango for quite a while.  It's still a very  
good library.  I don't think the reasons it won't be ported are technical.


-Steve

Re: "in" everywhere

[Steven Schveighoffer]

On Thu, 07 Oct 2010 07:54:14 -0400, atommixz  wrote:


It would be nice if it were possible to use the "in" expression wherever
possible. Now it is only implemented for associative. arrays. (Weird).
Examples of how this could be used:
- Find string in string
- Search for a character in a string
- Search for an item in the array, array of characters, array of strings,
tuples, enum, structure
- what else?


This has been suggested before.  The problem is that 'in' is generally  
considered to be a fast operation (< O(n)) so linear search is out.


-Steve

Re: What would you rewrite in D?

[Robert Clipsham]

On 07/10/10 00:28, Nick Sabalausky wrote:

Unless you're a KDE (or Xfce) user. Which actually brings up another thing:
It's my understanding that wxWidgets can use other things than just GTK on
Linux. And AIUI, Qt and KDE are tied togther in the same way as GTK and
GNOME, so does that mean Qt won't use GTK for Linux users running GNOME?


Dunno about GTK, you can set Qt to use your GTK theme though, thus 
keeping your theme in sync across both Qt and GTK apps.


--
Robert
http://octarineparrot.com/

Re: What would you rewrite in D?

[Robert Clipsham]

On 07/10/10 09:46, Jacob Carlborg wrote:

I haven't seen any native looking Qt application on Mac.


When did you last use a Qt application on a Mac? The cocoa backend for 
OS X is fairly new - Qt apps I've written look native on a Mac 
(admittedly the spacing's a bit off in places, that's not a huge issue 
though).


--
Robert
http://octarineparrot.com/

Re: Tuple literal syntax

[Simen kjaeraas]

Walter Bright  wrote:


(a,b,c)[0]

may be how the generative programming works, and that suggests:

(a,0)[0]

as how a user could generate a tuple of 1. Awkward, sure, but like I  
said, I think this would be rare.


Wouldn't (a,0)[0] currently return a, not (a)? The syntax that behaves
as you describe would be slicing: (a,0)[0..1].

This said, read bearophile's post "Re: Tuple literal syntax + Tuple
assignment". It seems well thought-out, and I agree with all his
points.

--
Simen

Re: "in" everywhere

[Daniel Gibson]

Steven Schveighoffer schrieb:

On Thu, 07 Oct 2010 07:54:14 -0400, atommixz  wrote:


It would be nice if it were possible to use the "in" expression wherever
possible. Now it is only implemented for associative. arrays. (Weird).
Examples of how this could be used:
- Find string in string
- Search for a character in a string
- Search for an item in the array, array of characters, array of strings,
tuples, enum, structure
- what else?


This has been suggested before.  The problem is that 'in' is generally 
considered to be a fast operation (< O(n)) so linear search is out.


-Steve


Is it?
I wouldn't expect it to be < O(n) on a regular array, but it'd still be 
convenient to have instead of iterating over the array and comparing the 
contents yourself.


Cheers,
- Daniel

Re: On C/C++ undefined behaviours (on the term "undefined behaviours")

[BCS]

Hello Stanislav,


I don't think that "invalid behavior" covers that sense: it means that
implementation should actually do something to make code perform
'invalid' things (what should be considered invalid, by the way?),
rather than have the possibility to best adapt the behavior to system
(e.g. segfault) or some error handling mechanism (e.g. throw an
exception).



Some where in the spec, D defines depending on order of evaluation to be 
invalid (placing any related bugs in your code, not the compiler, by fiat) 
but declines to requiter the compiler to enforce it (because it can't in 
many cases). Maybe some term for "invalid but un checked" should be used.


--
... <

Re: phobos is failure

[crap]

Steven Schveighoffer Wrote:

> On Wed, 06 Oct 2010 17:51:33 -0400, Nick Sabalausky  wrote:
> > IMHO, the primary reason for Tango has been eroding (at least for D2).  
> > As I
> > always saw it, the whole point of Tango was that Phobos was basically
> > early-alpha-level with practically no features, and no one actively  
> > working
> > on it (just a little bit of occasional attention from Walter). In those
> > days, Tango mage *perfect* sense. But Phobos2 has come such a long way,  
> > and
> > has the added bonus of not leaving you lost in epic package/class
> > hierarchies. I don't mean to bash Tango, I used it and loved it for a  
> > long
> > time. I'm just not sure it's really needed on D2.
> 
> As a library, I loved and used Tango for quite a while.  It's still a very  
> good library.  I don't think the reasons it won't be ported are technical.

Some traitors left the development team. 50% bullshit FUD claims about the 
attribution clause and other shit talk wrt the complexity of package 
hierarchies were necessary to Boost (pun intended) the adoption of the horrible 
template abusing bloat library (see the big executable OMG! threads). A Phobos 
oriented book (again with no attribution to Tango development in D's history) 
was written to bash Tango. Now we are wondering how this all happened. Exciting 
times!

Re: "in" everywhere

[Steven Schveighoffer]

On Thu, 07 Oct 2010 10:09:17 -0400, Daniel Gibson   
wrote:



Steven Schveighoffer schrieb:

On Thu, 07 Oct 2010 07:54:14 -0400, atommixz  wrote:

It would be nice if it were possible to use the "in" expression  
wherever

possible. Now it is only implemented for associative. arrays. (Weird).
Examples of how this could be used:
- Find string in string
- Search for a character in a string
- Search for an item in the array, array of characters, array of  
strings,

tuples, enum, structure
- what else?
 This has been suggested before.  The problem is that 'in' is generally  
considered to be a fast operation (< O(n)) so linear search is out.

 -Steve


Is it?
I wouldn't expect it to be < O(n) on a regular array, but it'd still be  
convenient to have instead of iterating over the array and comparing the  
contents yourself.


The problem is with generic code.  Generic code that accepts some type  
that defines the "in" operator.  What can that generic code expect for  
performance when using "in"?  As a general rule, generic programming must  
always assume the worst case, and if we have no rules for 'in', the worst  
case is linear.  Which means generic code may not use 'in' when it would  
be a fast operation.  Same thing with indexing.  Try sorting a 'random  
access' range which uses a linear search on opIndex, and see what the  
performance is.


In addition, arr.find(x) seems pretty simple to me.

-Steve

Re: phobos is failure

[dsimcha]

== Quote from crap (tas...@yesit.is)'s article
> the horrible template abusing bloat library

I'm sorry, but this is what I **like** about Phobos.  I really hate nominative
typing and traditional Java/C++-style OO for most things.  It's verbose, 
requires
too much design to be set in stone upfront, and is not all that flexible.  In my
own programs I tend to only use it when I really need flexibility at runtime, 
not
just at design/development or compile time, which is a minority of cases.
Furthermore, for most things a few megabytes of executable size bloat is **not a
practical issue**.  For the types of programs I tend to write at least, the disk
and memory space the code takes up (100s of KB to a few MB) is negligible 
compared
to the size of the data the at the code operates on (100s of MB).

Re: phobos is failure

[Daniel Gibson]

crap schrieb:


A Phobos oriented book (...) was written to bash Tango. 


?

Re: Tuple assignment

[Andrei Alexandrescu]

On 10/7/10 3:55 CDT, Pelle wrote:

On 10/07/2010 08:08 AM, Walter Bright wrote:

If expr represents a tuple, we (Andrei and I) were thinking about the
syntax:

auto (a, b, c, d) = expr;

being equivalent to:

auto t = expr; auto a = t[0]; auto b = t[1]; auto c = t[2 .. $];

You can also do this with arrays, such that:

float[3] xyz;
auto (x, y, z) = xyz;

The Lithpers among you will notice that this essentially provides a
handy car,cdr shortcut for tuples and arrays:

auto (car, cdr) = expr;


Python 3 uses:
car, *cdr = expr
a, *b, c = [1,2,3,4,5] # leaves a=1, b=[2,3,4], c=5

I would like D to have
(car, cdr...) = expr
(a, b..., c) = [1,2,3,4,5]

for the equivalent.

Our varargs syntax is b..., theirs is *b. So it mirrors a bit, there. :-)


Excellent idea!

Andrei

Re: Tuple literal syntax

[Andrei Alexandrescu]

On 10/7/10 5:39 CDT, retard wrote:

Thu, 07 Oct 2010 03:20:23 -0500, Andrei Alexandrescu wrote:


Sorry for being Debbie Downer in this thread, but I'm not seeing a lot
of progress here. This is nothing but a syntax cutesy that helps
Tuple!(A, B) and tuple(a, b) and leaves all other issues related to
tuples unresolved (I'm actually afraid that it exacerbates them).

One good thing about Tuple is that it allows names of fields, so
functions can return tuples with conveniently named fields, e.g.
Tuple!(bool, "found", size_t, "position") etc. without having to define
little structs everywhere and fostering simple, clear code on the caller
side.


Why do tuple fields need a name?


They don't always need, but oftentimes names are better than numeric 
constants.



Isn't this a new ad-hoc way to introduce
structural typing in D?


Well what is the old ad-hoc way? Anyhow, tuples are a prime candidate 
for structural typing. Currently Tuple does not support it.



I often start with tuples, but if it turns out
that the value is used in many places, it will be eventually replaced
with a struct (e.g. coordinates in a gui / gamedev) for better type
safety.


I don't see

struct Coord
{
int x, y, z;
}

one iota typesafer than

alias Tuple!(int, "x", int, "y", int, "z") Coord;

Clearly if you want to introduce protection, methods etc. then 
struct/class is the way to go. Tuples have their charter.



Even with structs the need for field names is very rare.


I don't know how to define a struct without naming its fields in C, C++, 
C#, or D. If I could, I'd seldom want to use magic indexes instead of 
descriptive names.



The real
need for tuples is in very special cases where the syntax needs to be
light.


auto r = fun(42);
writeln(r.foo, ": ", r.bar);

On the client side the syntax is very light. The definition of the 
function would need to specify the type name:


Tuple!(int, "foo", string, "bar") fun(int) {
...
}

I think much of the list of grievances against tuple limitations stems 
from a feeling that doing tuples without special syntax is "cheating". 
For my money, library tuples are eminently usable, and once we fix a 
couple of compiler bugs, they will be as good as (if not simpler, 
richer, and clearer than) a built-in facility. I do want to introduce 
syntax for expansion a la


auto (a, b) = foo(42);

because that's a common need that's not satisfiable via a library. But 
then I want to define the syntax in a general way so it works not only 
with tuples, but also with arrays and types that implement opIndex.



Andrei

Re: Tuple literal syntax

[Olivier Pisano]

Le 07/10/2010 09:44, Juanjo Alvarez a écrit :

On Wed, 06 Oct 2010 23:04:35 -0700, Walter Bright
 wrote:

(a,0)[0]






as how a user could generate a tuple of 1. Awkward, sure, but like

I said, I

think this would be rare.


Python uses:

(5,)
Which is a lot better IMHO


Vote++;

Re: "in" everywhere

[Andrei Alexandrescu]

On 10/7/10 6:54 CDT, atommixz wrote:

It would be nice if it were possible to use the "in" expression wherever
possible. Now it is only implemented for associative. arrays. (Weird).
Examples of how this could be used:
- Find string in string
- Search for a character in a string
- Search for an item in the array, array of characters, array of strings,
tuples, enum, structure
- what else?

In Python done something like this.

Here it would be useful to me
http://code.google.com/p/atommixz/source/browse/analyze-x86/analyze-x86.py
http://code.google.com/p/atommixz/source/browse/analyze-x86/analyzex86.d


I'm a bit leary of adopting this feature (it has been discussed). To me 
"in" implies a fast operation and substring searching isn't quite it.


One thing that could be done is to allow "in" with literal arrays to 
their right:


if (x in ["abcde", "asd"]) { ... }

The size of the operand is constant, known, and visible.


Andrei

Re: Is D right for me?

[Gour D.]

On Fri, 08 Oct 2010 00:24:52 +1100
>> "Justin" == Justin Johansson wrote:

Justin> I think that long are the days that a single individual (or
Justin> corporation) can "own" a language.  It will be an unwinnable
Justin> battle so long as the governance of D is under the auspices of
Justin> a single mortal.

I agree that, based on my short research about D, I see several
places with the label 'room for improvement' like (more) open
development process, using of DVCS, planning releases, better
organized web sites, up-to-date wiki, more docs etc.

Still, I believe that things are improving or, at least, there are
still people enthused with D. That's why I'm curious how to proceed my
evaluation phase in order to be able to properly decide for our
project? (Running 108 variations of "Hello world" is not adequate
test, neither of the language, nor for the tools.)

So, my question is whether is there some option to get more complete
coverage of the language (D2) besides TDPL book which will require
some time to arrive here in Croatia (I found that book is worthy
purchase no matter what we decide about D eventually)?

Justin> There is too much risk for investors of time let alone pecuniary
Justin> investors under the current regime.

I agree here...this is e.g. one of the reasons to cautious to invest
my time in learning & using ConTeXt (http://www.pragma-ade.com/)
seeing it practically as one-man-band mostly pushed by one developer
(Hans Hagen), no matter how talented he is and I'll continue using
LyX/LaTeX.

btw, my question on SO

(http://stackoverflow.com/questions/3863111/haskell-or-d-for-gui-desktop-application
 
or http://is.gd/fPK36)

got one nice response from Don Stewart who wrote: "Let's tease out
some requirements here, and I'll try to make the Haskell case. Perhaps
the D fans or others could try to do the same.", so it would be nice,
at least for other users, that some more experienced D user writes The
Case for D (no pun intended).


Sincerely,
Gour

-- 

Gour  | Hlapicina, Croatia  | GPG key: CDBF17CA



signature.asc
Description: PGP signature

Re: Tuple literal syntax

[Andrei Alexandrescu]

On 10/7/10 7:23 CDT, Justin Johansson wrote:

On 7/10/2010 5:04 PM, Walter Bright wrote:

There have been a couple of looong threads about tuples:

http://www.digitalmars.com/d/archives/digitalmars/D/Reddit_why_aren_t_people_using_D_93528.html


http://www.digitalmars.com/d/archives/digitalmars/D/Should_the_comma_operator_be_removed_in_D2_101321.html


A lot of it foundered on what the syntax for tuple literals should be.
The top of the list is simply enclosing them in ( ). The problem with
this is


Walter, please define exactly what a tuple is as being, both
in the context of your post and (presumably) in the D type system.

Without a precise definition of exactly what a tuple is,
your post will at best elucidate responses that also lack a
precise understanding of a tuple is (supposed to be).

There are already a number of responses to your post that focus
on syntax and without any semantic foundation.


Wise words! It was exactly what I protested against. It discusses syntax 
without attacking any of the actual issues.


Andrei

Re: "in" everywhere

[Daniel Gibson]

Andrei Alexandrescu schrieb:

On 10/7/10 6:54 CDT, atommixz wrote:

It would be nice if it were possible to use the "in" expression wherever
possible. Now it is only implemented for associative. arrays. (Weird).
Examples of how this could be used:
- Find string in string
- Search for a character in a string
- Search for an item in the array, array of characters, array of strings,
tuples, enum, structure
- what else?

In Python done something like this.

Here it would be useful to me
http://code.google.com/p/atommixz/source/browse/analyze-x86/analyze-x86.py 


http://code.google.com/p/atommixz/source/browse/analyze-x86/analyzex86.d


I'm a bit leary of adopting this feature (it has been discussed). To me 
"in" implies a fast operation and substring searching isn't quite it.


One thing that could be done is to allow "in" with literal arrays to 
their right:


if (x in ["abcde", "asd"]) { ... }

The size of the operand is constant, known, and visible.


Andrei


That feels inconsistent.. to be able to use it with "literal arrays to 
their right" (and what about fixed size arrays?) but not with actual 
arrays and dynamic arrays seems weird.


Cheers,
- Daniel

Re: Tuple literal syntax

[Michel Fortin]

On 2010-10-07 04:20:23 -0400, Andrei Alexandrescu 
 said:


Sorry for being Debbie Downer in this thread, but I'm not seeing a lot 
of progress here. This is nothing but a syntax cutesy that helps 
Tuple!(A, B) and tuple(a, b) and leaves all other issues related to 
tuples unresolved (I'm actually afraid that it exacerbates them).


One good thing about Tuple is that it allows names of fields, so 
functions can return tuples with conveniently named fields, e.g. 
Tuple!(bool, "found", size_t, "position") etc. without having to define 
little structs everywhere and fostering simple, clear code on the 
caller side.


I've always found tuples with named arguments awkward. I mean, a tuple 
is a list of



Also, obviously, empty tuples and tuples with one element are 
self-explanatory (Tuple!() and Tuple!(int) for types, tuple() and 
tuple(4) for values).


And then you have TypeTuple!(...) for tuples of types or 
statically-known values. The basic problem is that all these different 
syntaxes define slight variations of the same core tuple concept.


Giving a true syntax for tuples makes things *simpler* by reducing 
these variations. For instance, a TypeTuple!(int, int) isn't the same 
thing as Tuple!(int, int). Why is it so? Because of an implementation 
detail: one defines the core language tuple and the other defines a 
wrapper struct around the core tuple that implements what's basically 
missing in the core tuple implementation (returning from a function).


With Walter changes I expect you'll be able to call a function this way 
(simply because this is actually what happens when you use a real tuple 
in D):


auto a = (1, 2);
func(a); // same as func(a[0], a[1]);

Or you could have some kind of filter function that takes arbitrary 
arguments and transform them somehow before passing them to another 
function. For instance:


auto square(T...)(T tuple) {
foreach (ref element; tuple)
element ^= 2;
return tuple;
}

writefln("%d %d %d %d %d", square(1,2,3,4,5)); // prints "1 4 9 16 25"

I'm not inventing anything. This is exactly how the core language 
tuples work today in D. It's already possible to have core language 
tuples in variables (try creating a variable of type TypeTuple!(int, 
int), it works!). The only two things Walter is proposing to implement 
is tuple literals and tuple returns for functions.


And, if I'm guessing right, this syntax will also work:

int a;
float b;
(a, b) = func(); // func returns a (int, float) which is directly
 // stored in the right variables

This has been proven very useful in languages that supports it; heck, 
even C++ has this feature with boost::tie. I assume it'll work because, 
well, it already works if the tuple isn't the return value of a 
function call:


TypeTuple!(a, b) = TypeTuple!(1, 2);
TypeTuple!(a, b) = tuple(1, 2).fields;


Up until recently the syntax t[i] didn't work for tuples, forcing 
t.field[i]. This marginally improves usage of tuples. There are still 
other issues left due to compiler bugs; for example slicing t[a .. b] 
is supposed to work but it doesn't. But my question is, do we need more 
notation, more special cases, more ambiguities, more solution to 
ambiguities, more corner cases (there's already a request for handling 
void in a particular way)...? And for what? Quite literally because we 
refuse to call a tuple a tuple? I'm not seeing much gain here. 
Syntactic sugar is good in moderate quantities, but in Perlis' words 
this is bound to cause cancer of the semicolon.


I find it hard to see how obsoleting one of the two tuple concepts (the 
one in Phobos) and keeping only the core language tuple will introduce 
more bugs. The tuple concept is already at the core of the language, 
and it is quite needed there too for metaprogramming an other stuff. We 
can't remove it, so let's improve it instead of layering a wrapper over 
it, giving it same name, and making things more confusing for everyone.


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

Re: Ruling out arbitrary cost copy construction?

[Andrei Alexandrescu]

On 10/7/10 7:34 CDT, Michel Fortin wrote:

On 2010-10-07 02:09:04 -0400, Andrei Alexandrescu
 said:


I agree with all of the above. After all has been said and done, it
looks like uniform function call syntax is a pivotal feature for
simplifying ranges. Most ranges can simply define the basic
operations, and std.range takes care of defining boilerplate defaults
for a host of cases. For example, you just call r.moveFront() and that
becomes moveFront(r) which is defined by std.range.


That's good. I'm glad to see that using move semantics is still on the
table.

Another note, you don't really need to wait for the uniform function
call syntax for this to work. The moveFront function template in
std.range could check for the presence of moveFront in the range and
call it when available. This means you have to write moveFront(r)
everywhere instead of r.moveFront(), which might be an annoyance but at
least it works.


Turns out it's a lot more annoying in practice than I had imagined. I 
think I need to wait for uniform function call syntax.


Andrei

Re: Tuple literal syntax + Tuple assignment

[Simen kjaeraas]

bearophile  wrote:

In my opinion it's good for a built-in D tuple to be a structural type.  
This also means you are allowed to perform an == among two tuples of  
different length (the result is known statically to be always false).


I understand (and agree to) the opinion that tuples should be structural
types, but why allow comparison of tuples of different lengths?



Walter:

A lot of it foundered on what the syntax for tuple literals should be.  
The top

of the list is simply enclosing them in ( ).


This is a bad idea. It has caused troubles in Python because of the  
singleton syntax (tuple with 1 item).


One solution is to use a special unambigous delimiter to denote tuples,  
like (a similar solution is used in the Fortress language):



(|1, 2, 3, 4|)

Otherwise a good solution is to use a name:



record(1, 2, 3, 4)

I prefer the record() solution, but the first solution too acceptable.


Yeah, ( T... ) is not a good general tuple syntax. I believe auto( ) is
a free syntax in D, and thus could be used for tuples. Thinking more
about it, I am no longer as sure.



auto (car, cdr...) = expr;


I really like this.


Regarding field names for tuples, I have used Python and I like the  
optional names of D tuples (records). In some situations you don't need  
names, but in other situations field names are handy and help avoid  
bugs. In Python code that processes and uses tuples contains too many  
[0] [1] [2] etc that aren't readable and are bug-prone.


But a good management of such names asks for the names to not change the  
type of the tuple, this is why I talk about structural typing for  
records.



I wrote a Tuple implementation for D that supports structural typing:

http://pastebin.com/qeYKa5GZ

(see line 58-60 for proof)
This is a simple proof-of-concept, so don't expect anything impressive
from it.


--
Simen

Re: Tuple literal syntax

[retard]

Thu, 07 Oct 2010 09:46:59 -0500, Andrei Alexandrescu wrote:

> On 10/7/10 5:39 CDT, retard wrote:
>> Thu, 07 Oct 2010 03:20:23 -0500, Andrei Alexandrescu wrote:
>>
>>> Sorry for being Debbie Downer in this thread, but I'm not seeing a lot
>>> of progress here. This is nothing but a syntax cutesy that helps
>>> Tuple!(A, B) and tuple(a, b) and leaves all other issues related to
>>> tuples unresolved (I'm actually afraid that it exacerbates them).
>>>
>>> One good thing about Tuple is that it allows names of fields, so
>>> functions can return tuples with conveniently named fields, e.g.
>>> Tuple!(bool, "found", size_t, "position") etc. without having to
>>> define little structs everywhere and fostering simple, clear code on
>>> the caller side.
>>
>> Why do tuple fields need a name?
> 
> They don't always need, but oftentimes names are better than numeric
> constants.

If some compile time voodoo isn't used, the names have an effect on the 
performance (runtime lookups).

> 
>> Isn't this a new ad-hoc way to introduce structural typing in D?
> 
> Well what is the old ad-hoc way? Anyhow, tuples are a prime candidate
> for structural typing. Currently Tuple does not support it.

I have nothing against the structural typing of tuples, per se. I meant 
structural typing in the sense that Scala implements it -- a set of name-
value pairs constructs a new type. It seems to require runtime 
dictionaries in their implementation.

> 
>> I often start with tuples, but if it turns out that the value is used
>> in many places, it will be eventually replaced with a struct (e.g.
>> coordinates in a gui / gamedev) for better type safety.
> 
> I don't see
> 
> struct Coord
> {
>  int x, y, z;
> }
> 
> one iota typesafer than
> 
> alias Tuple!(int, "x", int, "y", int, "z") Coord;

I meant the naming of the aggregate vs not naming it. Passing around n-
tuples without any name associated for the concept allows mixing n-tuples 
if the internal type structure matches. Sometimes I want to distinguish 
between the uses. Clearly some coordinate in the game world shouldn't 
automatically be applicable in the GUI context:

struct GameCoord {
  int x,y,z;
}

struct GUICoord {
  int x,y,z;
}

// void drawOval(GUICoord); // fun prototype

GameCoord a;
drawOval(a); // bang

This might lead to bugs if the compiler silently accepts a wrong 
aggregate.

>> Even with structs the need for field names is very rare.
> 
> I don't know how to define a struct without naming its fields in C, C++,
> C#, or D. If I could, I'd seldom want to use magic indexes instead of
> descriptive names.

I didn't know what the template creates. I had an impression that it 
creates an array of strings for some runtime purposes, like:

foreach(value; tuple) {
  writefln("%s is %s", value.name, value);
}

So I was just refering to those runtime string literals. Maybe I confused 
this with some enum related template.

 
>> The real
>> need for tuples is in very special cases where the syntax needs to be
>> light.
> 
> auto r = fun(42);
> writeln(r.foo, ": ", r.bar);
> 
> On the client side the syntax is very light. The definition of the
> function would need to specify the type name:
> 
> Tuple!(int, "foo", string, "bar") fun(int) {
>  ...
> }

We have an issue with terminology here. To me that isn't a *tuple*, it's 
a record! A tuple would let you choose the variable names on the client 
side:

auto (foo, bar) = fun(42);

writeln(foo, ": ", bar);

Re: Tuple literal syntax

[Kagamin]

Andrei Alexandrescu Wrote:

> struct Coord
> {
>  int x, y, z;
> }
> 
> one iota typesafer than
> 
> alias Tuple!(int, "x", int, "y", int, "z") Coord;

Is there a real need for an alternative way to declare structs?

Re: Tuple literal syntax

[Simen kjaeraas]

retard  wrote:


Why do tuple fields need a name?


They don't always need, but oftentimes names are better than numeric
constants.


If some compile time voodoo isn't used, the names have an effect on the
performance (runtime lookups).


What? You really think structs/tuples are implemented like
Variant[string]?

foo.bar => *(&foo + bar.offsetof), where offsetof is known at
compiletime. It doesn't get faster than that.

--
Simen

Re: Tuple literal syntax + Tuple assignment

[Andrei Alexandrescu]

On 10/7/10 7:09 CDT, bearophile wrote:

In the two threads (that are a single thread) most of the things I've seen are 
bad/wrong.

I have discussed about Tuples several times in the D newsgroup and in Bugzilla. 
Please don't ignore all my work.

Before designing tuple syntax you must decide what the purpose of D tuples is. 
Then you have to solve the design problems, and avoid all (or most) corner 
cases. In this discussion it's useful to have a certain experience of languages 
that use tuples often, as Python and others.


Good point.


Tuples have some purposes:
- Python, Go and other languages show that it's handy to allow functions to 
return multiple values, this means a tuple.
- A handy tuple unpacking is useful at the calling point of a function that 
returns multiple return values.
- Tuples are also useful as quick-and-dirty structs, to sort items in a 
different order, etc.

It's useful to use [] to access tuple items, to slice tuples, concat them. It's 
useful for tuples to have a good textual representation, to be comparable 
lexicographically and to be hashable.


Yes, excellent. Now I realize we don't have hash for tuples just yet.


Another design decision is if tuples have a nominative or structural type, this 
problem comes out in this bug report:
http://d.puremagic.com/issues/show_bug.cgi?id=4128

In my opinion it's good for a built-in D tuple to be a structural type. This 
also means you are allowed to perform an == among two tuples of different 
length (the result is known statically to be always false). I assume that D 
tuples know their length at compile-time.


Yah, I think tuples are the quintessential structural types. I think, 
however, that "==" shouldn't test for prefix (that would be 
_sub_typing). This is because slicing takes care of it. For example:


Tuple!(int, int, int) point3d;
Tuple!(int, int) point2d;
point2d == point3d; // doesn't compile
point2d == point3d[0 .. point2d.length]; // compiles


Another significant problem is about naming things, currently the situation is 
a mess:
http://www.digitalmars.com/d/archives/digitalmars/D/Tuple_TypeTuple_tupleof_etc_113005.html
http://d.puremagic.com/issues/show_bug.cgi?id=4113
In the end I have suggested to name "record" the typecons tuples, and "tuple" 
the typetuples.


I think we're in good shape with Tuple and tuple. The "other" tuples 
deserve an odder name.



I have several bug reports and enhancement requests about tuples, please take 
them into account:

http://d.puremagic.com/issues/show_bug.cgi?id=4577
http://d.puremagic.com/issues/show_bug.cgi?id=4582
http://d.puremagic.com/issues/show_bug.cgi?id=4591
http://d.puremagic.com/issues/show_bug.cgi?id=4666
http://d.puremagic.com/issues/show_bug.cgi?id=4846


Nice. I like at least some of each.


Walter:


A lot of it foundered on what the syntax for tuple literals should be. The top
of the list is simply enclosing them in ( ).


This is a bad idea. It has caused troubles in Python because of the singleton 
syntax (tuple with 1 item).


During our conversation I conveyed my suspicion that that one corner 
case (which is very often encountered in generic code) will inevitably 
do this whole thing in, but he was quick to gloss over the issues. I'd 
be glad to have experience with Python save us some sweat. Do you have 
any links to discussions regarding the matter?



One solution is to use a special unambigous delimiter to denote tuples, like (a 
similar solution is used in the Fortress language):

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


Yup, the banana notation.


Otherwise a good solution is to use a name:

record()
record(1)
record(1, 2)
record(1, 2, 3)
record(1, 2, 3, 4)

I prefer the record() solution, but the first solution too acceptable.


How about the shorter "tuple"? Wait, it's already there :o).


Finally, I got to thinking, why not just make it a special case:

   ( ) == tuple
   (a) == parenthesized expression


This is not acceptable. No special cases, please. D has already a ton of 
special cases.
Python solves this with the (1,) syntax, but it's not nice, it's error-prone, 
and it confuses newbies.


Evidence please?


If expr represents a tuple, we (Andrei and I) were thinking about the syntax:

  auto (a, b, c, d) = expr;


On this topic I have this enhancement request:
http://d.puremagic.com/issues/show_bug.cgi?id=4579



The Lithpers among you will notice that this essentially provides a handy
car,cdr shortcut for tuples and arrays:

  auto (car, cdr) = expr;


This is bad, it's not explicit enough. If you want to support this semantics then the 
syntax has to show what you mean. Python uses a * to denote "grab the whole 
tail". In D you may use something else, others have suggested tree points, this 
works with dynamic arrays too:

auto (car, cdr...) = expr;


Nice.


Regarding field names for tuples, I have used Python and I like the optional 
names of D tuples (records). In some situations you don't need names, but in 
other situ

Re: Tuple literal syntax

[Andrei Alexandrescu]

On 10/7/10 10:13 CDT, Kagamin wrote:

Andrei Alexandrescu Wrote:


struct Coord
{
  int x, y, z;
}

one iota typesafer than

alias Tuple!(int, "x", int, "y", int, "z") Coord;


Is there a real need for an alternative way to declare structs?


Yes.

Andrei

Re: "in" everywhere

[Andrei Alexandrescu]

On 10/7/10 9:59 CDT, Daniel Gibson wrote:

Andrei Alexandrescu schrieb:

On 10/7/10 6:54 CDT, atommixz wrote:

It would be nice if it were possible to use the "in" expression wherever
possible. Now it is only implemented for associative. arrays. (Weird).
Examples of how this could be used:
- Find string in string
- Search for a character in a string
- Search for an item in the array, array of characters, array of
strings,
tuples, enum, structure
- what else?

In Python done something like this.

Here it would be useful to me
http://code.google.com/p/atommixz/source/browse/analyze-x86/analyze-x86.py

http://code.google.com/p/atommixz/source/browse/analyze-x86/analyzex86.d


I'm a bit leary of adopting this feature (it has been discussed). To
me "in" implies a fast operation and substring searching isn't quite it.

One thing that could be done is to allow "in" with literal arrays to
their right:

if (x in ["abcde", "asd"]) { ... }

The size of the operand is constant, known, and visible.


Andrei


That feels inconsistent.. to be able to use it with "literal arrays to
their right" (and what about fixed size arrays?) but not with actual
arrays and dynamic arrays seems weird.


It's not. It's all about constant size in the size of the input vs. 
arbitrary size. Makes perfect sense to me.


Andrei

Re: Tuple literal syntax

[Andrei Alexandrescu]

On 10/7/10 10:22 CDT, Simen kjaeraas wrote:

retard  wrote:


Why do tuple fields need a name?


They don't always need, but oftentimes names are better than numeric
constants.


If some compile time voodoo isn't used, the names have an effect on the
performance (runtime lookups).


What? You really think structs/tuples are implemented like
Variant[string]?

foo.bar => *(&foo + bar.offsetof), where offsetof is known at
compiletime. It doesn't get faster than that.



Yah, this is D dammit :o).

Andrei

Re: Tuple literal syntax

[retard]

Thu, 07 Oct 2010 17:22:08 +0200, Simen kjaeraas wrote:

> retard  wrote:
> 
 Why do tuple fields need a name?
>>>
>>> They don't always need, but oftentimes names are better than numeric
>>> constants.
>>
>> If some compile time voodoo isn't used, the names have an effect on the
>> performance (runtime lookups).
> 
> What? You really think structs/tuples are implemented like
> Variant[string]?
> 
> foo.bar => *(&foo + bar.offsetof), where offsetof is known at
> compiletime. It doesn't get faster than that.

There are several conflicting concepts at stake here. I guess the 
nominative typing is quite clear -- the type name fully dictates the 
physical and logical form of the data.

But structural typing can be implemented in several ways. I use the name 
'record' for tuples with field names. This notation doesn't necessarily 
define any physical order of fields in the memory. When you bring an 
aggregate from the tuple world to the struct world, you have to lock down 
some physical layout for the data.

If you don't have first class tuple constructors and define them with a 
template, that's unfortunately not structural typing. The D's structs 
might use the copying semantics from structural typing, but it's a weird 
hybrid type, actually. Just like the tuples aren't real tuples. Field 
names break the definition. Type tuples break it, too.

Re: Is D right for me?

[bioinfornatics]

For me i will use D1 while ldc do not support D2 or if GDC come a GCC
project and support D2. Until this is not done a big community part do
not go to D2.

Re: "in" everywhere

[Daniel Gibson]

Andrei Alexandrescu schrieb:

On 10/7/10 9:59 CDT, Daniel Gibson wrote:

Andrei Alexandrescu schrieb:

On 10/7/10 6:54 CDT, atommixz wrote:
It would be nice if it were possible to use the "in" expression 
wherever

possible. Now it is only implemented for associative. arrays. (Weird).
Examples of how this could be used:
- Find string in string
- Search for a character in a string
- Search for an item in the array, array of characters, array of
strings,
tuples, enum, structure
- what else?

In Python done something like this.

Here it would be useful to me
http://code.google.com/p/atommixz/source/browse/analyze-x86/analyze-x86.py 



http://code.google.com/p/atommixz/source/browse/analyze-x86/analyzex86.d 



I'm a bit leary of adopting this feature (it has been discussed). To
me "in" implies a fast operation and substring searching isn't quite it.

One thing that could be done is to allow "in" with literal arrays to
their right:

if (x in ["abcde", "asd"]) { ... }

The size of the operand is constant, known, and visible.


Andrei


That feels inconsistent.. to be able to use it with "literal arrays to
their right" (and what about fixed size arrays?) but not with actual
arrays and dynamic arrays seems weird.


It's not. It's all about constant size in the size of the input vs. 
arbitrary size. Makes perfect sense to me.




So what about static arrays?

Cheers,
- Daniel

Re: "in" everywhere

[Andrei Alexandrescu]

On 10/7/10 10:39 CDT, Daniel Gibson wrote:

Andrei Alexandrescu schrieb:

On 10/7/10 9:59 CDT, Daniel Gibson wrote:

Andrei Alexandrescu schrieb:

On 10/7/10 6:54 CDT, atommixz wrote:

It would be nice if it were possible to use the "in" expression
wherever
possible. Now it is only implemented for associative. arrays. (Weird).
Examples of how this could be used:
- Find string in string
- Search for a character in a string
- Search for an item in the array, array of characters, array of
strings,
tuples, enum, structure
- what else?

In Python done something like this.

Here it would be useful to me
http://code.google.com/p/atommixz/source/browse/analyze-x86/analyze-x86.py


http://code.google.com/p/atommixz/source/browse/analyze-x86/analyzex86.d



I'm a bit leary of adopting this feature (it has been discussed). To
me "in" implies a fast operation and substring searching isn't quite
it.

One thing that could be done is to allow "in" with literal arrays to
their right:

if (x in ["abcde", "asd"]) { ... }

The size of the operand is constant, known, and visible.


Andrei


That feels inconsistent.. to be able to use it with "literal arrays to
their right" (and what about fixed size arrays?) but not with actual
arrays and dynamic arrays seems weird.


It's not. It's all about constant size in the size of the input vs.
arbitrary size. Makes perfect sense to me.



So what about static arrays?


Same deal - same as literal arrays: they can be searched. The expected 
run time is known during compilation and independent of the input size.


Andrei

Re: Is D right for me?

[Gour D.]

On Thu, 7 Oct 2010 15:36:36 + (UTC)
>> "bioinfornatics" ==  wrote:

bioinfornatics> For me i will use D1 while ldc do not support D2 or if
bioinfornatics> GDC come a GCC project and support D2. Until this is
bioinfornatics> not done a big community part do not go to D2.

Hmm...based on that I saw, I consider that D2 features are much more
compelling when comparing D with Haskell...Hopefully, in a few months
some things may change in D2 arena...


Sincerely,
Gour

-- 

Gour  | Hlapicina, Croatia  | GPG key: CDBF17CA



signature.asc
Description: PGP signature

Re: phobos is failure

[dolive]

Daniel Gibson дµ½:

> crap schrieb:
> > 
> > A Phobos oriented book (...) was written to bash Tango. 
> 
> ?
He write is Chinese about. :-)

Re: phobos is failure

[Andrei Alexandrescu]

On 10/7/10 9:37 CDT, dsimcha wrote:

== Quote from crap (tas...@yesit.is)'s article

the horrible template abusing bloat library


I'm sorry, but this is what I **like** about Phobos.  I really hate nominative
typing and traditional Java/C++-style OO for most things.  It's verbose, 
requires
too much design to be set in stone upfront, and is not all that flexible.  In my
own programs I tend to only use it when I really need flexibility at runtime, 
not
just at design/development or compile time, which is a minority of cases.
Furthermore, for most things a few megabytes of executable size bloat is **not a
practical issue**.  For the types of programs I tend to write at least, the disk
and memory space the code takes up (100s of KB to a few MB) is negligible 
compared
to the size of the data the at the code operates on (100s of MB).


One other thing is that it's very easy to build traditional designs on 
top of highly configurable ones (like Phobos tries to offer), whereas 
the reverse is not possible (or at least not efficiently).


I noticed that some tend to think that if they see Phobos going the 
extra length to define a really general, flexible, and adaptive 
algorithm or structure, they're forced to write application code all the 
same. If we align our ducks right, Phobos should be a compelling 
offering to a large range of designs.



Andrei

Re: Tuple assignment

[Leandro Lucarella]

Andrei Alexandrescu, el  7 de octubre a las 03:20 me escribiste:
> On 10/7/10 1:43 CDT, Russel Winder wrote:
> >On Wed, 2010-10-06 at 23:08 -0700, Walter Bright wrote:
> >>If expr represents a tuple, we (Andrei and I) were thinking about the 
> >>syntax:
> >>
> >>  auto (a, b, c, d) = expr;
> >>
> >>being equivalent to:
> >>
> >>  auto t = expr; auto a = t[0]; auto b = t[1]; auto c = t[2 .. $];

I guess d being missing is a typo, right?

> >>You can also do this with arrays, such that:
> >>
> >>  float[3] xyz;
> >>  auto (x, y, z) = xyz;
> >>
> >>The Lithpers among you will notice that this essentially provides a handy
> >>car,cdr shortcut for tuples and arrays:
> >>
> >>  auto (car, cdr) = expr;
> >
> >
> >Python may be the best base to compare things to as tuple assignment has
> >been in there for years.
> >
> >Pythons choice is not a car/cdr approach but an exact match approach.
> 
> So then we'd have the proposed notation not work with dynamic arrays
> - only with static arrays and tuples.

Unless you add a dynamic "bound" check as when accessing a dynamic array
item, something like:

auto t = expr; assert (t.lenght == 4); auto a = t[0]; auto b = t[1];
auto c = t[2]; auto d = t[3];

I like the idea of having exact match approach and the explicit syntax
for getting the rest as Brad said. But in all the years I used Python,
I never needed that syntax, maybe because most of the times when I use
the tuple expansion I know the size or I want to truncate, or I use
something to generate the data, like split(), that takes an extra
parameter to do that:

l = [1, 2, 3]
a, b, c = l  # known lenght
a, b = l[:2] # truncation (like l[0..2] in D)
a, b = '1,2,3'.split(',', 1) # get the rest in b (but it will be a string)
car, cdr = l[0], l[1:]   # just a little more verbose

-- 
Leandro Lucarella (AKA luca) http://llucax.com.ar/
--
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
--
careful to all animals (never washing spiders down the plughole),
keep in contact with old friends (enjoy a drink now and then),
will frequently check credit at (moral) bank (hole in the wall),

Re: Tuple literal syntax + Tuple assignment

[kenji hara]

2010/10/7 bearophile :
> Another design decision is if tuples have a nominative or structural type, 
> this problem comes out in this bug report:
> http://d.puremagic.com/issues/show_bug.cgi?id=4128

> Another significant problem is about naming things, currently the situation 
> is a mess:
> http://www.digitalmars.com/d/archives/digitalmars/D/Tuple_TypeTuple_tupleof_etc_113005.html
> http://d.puremagic.com/issues/show_bug.cgi?id=4113
> In the end I have suggested to name "record" the typecons tuples, and "tuple" 
> the typetuples.

On these issues, I'm almost agreed with bearophile

I think we may not use 'Tuple' as 'a structure packed values'.
It is more better that 'Tuple' should *only* use as mixing sequence
types and values.

My proposals are:
1. We should name definitions of structures.
 - "Structure that all of fields have name" shuld be called 'Struct'.
 - "Structure that some of fields have name" shuld be called 'Odd struct'.
 - "Structure that none of fields have name" shuld be called 'Record'.

 Struct∈Odd struct∈Record

2. We remove field namming funcion from std.typecons.tuple, and rename
it to Record.

3. We rename std.typetuple.TypeTuple to Tuple.


pseudo codes:

auto a = Record!(int, int)(10, 20);
auto b = Struct!(int, "x", int, "y")(100, 200);
//a = b; //should not compile, named field(x, y) cannot assign to unnamed field
b = a;   //should compile, unnamed field can assign to named field
assert(b[0] == 10);
assert(b[1] == 20);

auto c = OddStruct!(int, "x", int)(15, 25);
//a = c; //shuld not compile, named field(x) cannot assign to unnamed field
b = c;   //shuld compile
assert(b[0] == 15);
assert(b[1] == 25);
c = a;   //shuld compile
assert(c[0] == 10);
assert(c[1] == 20);

thanks.

Kenji Hara.

Re: Tuple literal syntax

[Michel Fortin]

On 2010-10-07 02:04:35 -0400, Walter Bright  said:


There have been a couple of looong threads about tuples:

http://www.digitalmars.com/d/archives/digitalmars/D/Reddit_why_aren_t_people_using_D_93528.html


http://www.digitalmars.com/d/archives/digitalmars/D/Should_the_comma_operator_be_removed_in_D2_101321.html

A 


lot of it foundered on what the syntax for tuple literals should be. 
The top of the list is simply enclosing them in ( ). The problem with 
this is


  (expression)

Is that a parenthesized expression, or a tuple? This really matters, 
since (e)[0] means very different things for the two.



Finally, I got to thinking, why not just make it a special case:


  ( ) == tuple
  (a) == parenthesized expression
  (a,b) == tuple
  (a,b,c) == tuple
  (a,b,c,d) == tuple

etc.


Seems good. I know some people have complained about the lack of a 
semantic foundation, but my understanding is that this is simply a 
syntax to define the same kind of tuple as you get with variadic 
template arguments or variables made from types defined as variadic 
template arguments. The semantic foundation is already there and in use 
with variadic templates, it just lacks a few features (literals and the 
ability to be a return type).


If this can be used in place of both Tuple!() and TypeTuple!() defined 
in Phobos, then it'll be great as we'll no longer need to have two 
distinct tuple concepts: one in the language and another Tuple!() 
wrapper that sits top of it just so we can return a tuple from a 
function.


For the syntax, I'd like to second Juanjo's suggestion to mimic Python 
for the one-element tuple:


(a,) == tuple

And Don's extension of that suggestion that it always accept a trailing 
comma like enums and array literals:


(a,b,) == tuple
(a,b,c,) == tuple


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

Re: Tuple literal syntax + Tuple assignment

[Andrei Alexandrescu]

On 10/7/10 11:11 CDT, kenji hara wrote:
> 2010/10/7 bearophile:
>> Another design decision is if tuples have a nominative or structural type, 
>> this problem comes out in this bug report:
>> http://d.puremagic.com/issues/show_bug.cgi?id=4128
> 
>> Another significant problem is about naming things, currently the situation 
>> is a mess:
>> http://www.digitalmars.com/d/archives/digitalmars/D/Tuple_TypeTuple_tupleof_etc_113005.html
>> http://d.puremagic.com/issues/show_bug.cgi?id=4113
>> In the end I have suggested to name "record" the typecons tuples, and 
>> "tuple" the typetuples.
> 
> On these issues, I'm almost agreed with bearophile
> 
> I think we may not use 'Tuple' as 'a structure packed values'.
> It is more better that 'Tuple' should *only* use as mixing sequence
> types and values.

The problem with this is that it departs from nomenclature that is
agreed by everyone else, which is provincial.

First off, a tuple IS agreed to be an ordered collection of
heterogeneous items. Google reveals copious evidence, both in math and
programming language theory.

Benjamin Pierce's "Types and programming languages", a book that all PL
students sleep with under their pillow, defines tuples in section 11.7
(entitled "Tuples") like D does. The first paragraph:

"It is easy to generalize the binary products of the previous section to
n-ary products, often called tuples. For example, {1,2,true} is a
3-tuple containing two numbers and a Boolean. Its type is written
{Nat,Nat,Bool}."

The following section defines records as tuples with labeled fields. I
don't think it's a crime that D calls both tuples. We could define
Record just to be more Catholic than the Pope, but I don't see a
necessity there. At any rate, "Tuple" is correct, known, understood, and
accepted.

D's built in type tuples (those used with TypeTuple) are weird. They are
an artifact of the language that has no meaning outside it. Such tuples
are defined as "anything that could be a template parameter", which
really ties them to various language design decisions. My suggestion is
that we deprecate TypeTuple and we call it AliasTuple because that's
really what it is - it's a tuple of stuff that can be passed in as an
alias parameter.

> My proposals are:
> 1. We should name definitions of structures.
>   - "Structure that all of fields have name" shuld be called 'Struct'.
>   - "Structure that some of fields have name" shuld be called 'Odd struct'.
>   - "Structure that none of fields have name" shuld be called 'Record'.
> 
>   Struct∈Odd struct∈Record
> 
> 2. We remove field namming funcion from std.typecons.tuple, and rename
> it to Record.
> 
> 3. We rename std.typetuple.TypeTuple to Tuple.
> 
> 
> pseudo codes:
> 
> auto a = Record!(int, int)(10, 20);

This is not a record by Pierce.

> auto b = Struct!(int, "x", int, "y")(100, 200);

This is a record by Pierce.

> auto c = OddStruct!(int, "x", int)(15, 25);

We could reject this during compilation if needed.

I don't see anything confusing grouping the above under "Tuple".


Andrei

Re: "in" everywhere

[Marianne Gagnon]

IMO this could be added, with the documentation specifying the implementation 
doesn't need to best fast. So people who want quick development for things that 
don't need high performance may use it, while people coding for performance 
just need not use it. The compiler may try to optimize it if it can.

I have seen python programs avoid the use of "in" since it was slower

About substring I don't know, though. But I think it makes sense for 
collections (arrays) and opIn or so could be added so other types of 
collections may use the "in" keyword perhaps

-- Auria

> On 10/7/10 6:54 CDT, atommixz wrote:
> I'm a bit leary of adopting this feature (it has been discussed). To me 
> "in" implies a fast operation and substring searching isn't quite it.
> 
> One thing that could be done is to allow "in" with literal arrays to 
> their right:
> 
> if (x in ["abcde", "asd"]) { ... }
> 
> The size of the operand is constant, known, and visible.
> 
> 
> Andrei

Re: "in" everywhere

[Michel Fortin]

On 2010-10-07 11:47:21 -0400, Andrei Alexandrescu 
 said:



On 10/7/10 10:39 CDT, Daniel Gibson wrote:

Andrei Alexandrescu schrieb:

On 10/7/10 9:59 CDT, Daniel Gibson wrote:

Andrei Alexandrescu schrieb:

On 10/7/10 6:54 CDT, atommixz wrote:

It would be nice if it were possible to use the "in" expression
wherever
possible. Now it is only implemented for associative. arrays. (Weird).
Examples of how this could be used:
- Find string in string
- Search for a character in a string
- Search for an item in the array, array of characters, array of
strings,
tuples, enum, structure
- what else?

In Python done something like this.

Here it would be useful to me
http://code.google.com/p/atommixz/source/browse/analyze-x86/analyze-x86.py


http://code.google.com/p/atommixz/source/browse/analyze-x86/analyzex86.d



I'm a bit leary of adopting this feature (it has been discussed). To
me "in" implies a fast operation and substring searching isn't quite
it.

One thing that could be done is to allow "in" with literal arrays to
their right:

if (x in ["abcde", "asd"]) { ... }

The size of the operand is constant, known, and visible.


Andrei


That feels inconsistent.. to be able to use it with "literal arrays to
their right" (and what about fixed size arrays?) but not with actual
arrays and dynamic arrays seems weird.


It's not. It's all about constant size in the size of the input vs.
arbitrary size. Makes perfect sense to me.



So what about static arrays?


Same deal - same as literal arrays: they can be searched. The expected 
run time is known during compilation and independent of the input size.


What about a static array of 20 elements? At which point does it 
become linear?


I'm okay with it for compile-time constant literals, because the values 
are known at compile time and the compiler can optimize the search at 
compile time (so it doesn't have to be linear), but for static array 
where the content isn't known at compile time, I'd not allow it.


Perhaps it could be allowed with a tuple. :-)

if (x in ("abcde", "asd")) { ... }

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

Re: Tuple literal syntax

[Simen kjaeraas]

retard  wrote:


If you don't have first class tuple constructors and define them with a
template, that's unfortunately not structural typing.


Might I inquire as to why?

As far as I can see, one can regard a structural type as a set of types,
fields, if you will. Each element of this set has some properties, which
would have to be equal to those of an element of a similar set in an
equal type. That is, (int, string) may be equal to (string, int) if one
considers index not to be one of those properties.

Some structural type systems will consider names part of those properties,
leading (string a, int b) to be equivalent to (int b, string a), if, as
before, index is not an interesting property.

By choosing opposite in these choices (index is important, name is not),
I cannot see that the premise of a structural type system is broken. In
this system, (int b, string a) != (string a, int b), and
(string a, int b) == (string b, int a).

Either of these choices can be implemented in D (the latter I have
implemented), so I cannot quite see where you are going with this.


The D's structs
might use the copying semantics from structural typing, but it's a weird
hybrid type, actually.


In this I agree. Well, given that in D a struct name in D would be unique
(bar linker fuckups), I would argue it is nominative.


--
Simen

Re: "in" everywhere

[Jonathan M Davis]

On Thursday, October 07, 2010 08:37:19 Andrei Alexandrescu wrote:
> >> 
> >> I'm a bit leary of adopting this feature (it has been discussed). To
> >> me "in" implies a fast operation and substring searching isn't quite it.
> >> 
> >> One thing that could be done is to allow "in" with literal arrays to
> >> their right:
> >> 
> >> if (x in ["abcde", "asd"]) { ... }
> >> 
> >> The size of the operand is constant, known, and visible.
> >> 
> >> 
> >> Andrei
> > 
> > That feels inconsistent.. to be able to use it with "literal arrays to
> > their right" (and what about fixed size arrays?) but not with actual
> > arrays and dynamic arrays seems weird.
> 
> It's not. It's all about constant size in the size of the input vs.
> arbitrary size. Makes perfect sense to me.
> 
> Andrei

It feels inconsistent because it only works on a particular type (arrays) some 
of the time. At least with associative arrays it _always_ works. You don't have 
to worry about whether it's legal in a particular context. Being able to use in 
on only a subset of arrays (like array literals) would not be consistent with 
regards to type (even if it's consistent with regards to complexity) and could 
lead to confusion.

Personally, I think that find() and indexof() do the the job just fine and I 
see 
no need to expand in. Regardless, I certainly don't want to have in working on 
arrays only some of the time. I completely agree with Daniel that doing so 
would 
be inconsistent.

- Jonathan M Davis

Re: "in" everywhere

[Austin Hastings]

On 10/7/2010 10:52 AM, Andrei Alexandrescu wrote:

On 10/7/10 6:54 CDT, atommixz wrote:

It would be nice if it were possible to use the "in" expression wherever
possible. Now it is only implemented for associative. arrays. (Weird).
Examples of how this could be used:
- Find string in string
- Search for a character in a string
- Search for an item in the array, array of characters, array of strings,
tuples, enum, structure
- what else?

In Python done something like this.

Here it would be useful to me
http://code.google.com/p/atommixz/source/browse/analyze-x86/analyze-x86.py

http://code.google.com/p/atommixz/source/browse/analyze-x86/analyzex86.d


I'm a bit leary of adopting this feature (it has been discussed). To me
"in" implies a fast operation and substring searching isn't quite it.

One thing that could be done is to allow "in" with literal arrays to
their right:

if (x in ["abcde", "asd"]) { ... }

The size of the operand is constant, known, and visible.


Andrei


This is a non-argument. "In" is an operator. "*" is an operator. 
Everyone "knew" that multiplying longs was slower than multiplying ints. 
Everyone "knew" that multiplying floating point was slower than 
multiplying integers. But * was still defined for floating point types 
because it made sense.


If querying a collection for the presence of a key makes sense (and it 
does to me) then the operator should work across as many collections as 
possible, regardless of the running time.


(The presence of optimized variations is a bonus. Not a requirement.)

=Austin

Re: "in" everywhere

[Steven Schveighoffer]

On Thu, 07 Oct 2010 13:28:51 -0400, Austin Hastings   
wrote:



On 10/7/2010 10:52 AM, Andrei Alexandrescu wrote:

On 10/7/10 6:54 CDT, atommixz wrote:
It would be nice if it were possible to use the "in" expression  
wherever

possible. Now it is only implemented for associative. arrays. (Weird).
Examples of how this could be used:
- Find string in string
- Search for a character in a string
- Search for an item in the array, array of characters, array of  
strings,

tuples, enum, structure
- what else?

In Python done something like this.

Here it would be useful to me
http://code.google.com/p/atommixz/source/browse/analyze-x86/analyze-x86.py

http://code.google.com/p/atommixz/source/browse/analyze-x86/analyzex86.d


I'm a bit leary of adopting this feature (it has been discussed). To me
"in" implies a fast operation and substring searching isn't quite it.

One thing that could be done is to allow "in" with literal arrays to
their right:

if (x in ["abcde", "asd"]) { ... }

The size of the operand is constant, known, and visible.


Andrei


This is a non-argument. "In" is an operator. "*" is an operator.  
Everyone "knew" that multiplying longs was slower than multiplying ints.  
Everyone "knew" that multiplying floating point was slower than  
multiplying integers. But * was still defined for floating point types  
because it made sense.


No, this is not just a difference in runtime, this is a difference in  
complexity.  The complexity of in on an associative array is O(1), the  
complexity of in on an array is O(n).  This is a huge difference from  
comparing multiplying floats and ints.


in's complexity should be O(lg(n)) or better.

I also disagree with Andrei that in could work on arrays in certain  
cases.  It has no business being called on an array, we already have find.


-Steve

Re: OwnerTerminated graceful handling

[Sean Kelly]

Eitan Frachtenberg Wrote:

> N00b question: Based on the TPDL, explicitly receive()ing OwnerTerminated 
> prevents an exception from throwing when the owner thread terminates. Yet 
> this is exactly what happens in the following code:
> 
> import std.concurrency;
> 
> void thr() {
> receive(
>   (OwnerTerminated) { return; }
>);
> }
> 
> void main() {
>   spawn(&thr);
> }
> 
> Try to wrap the receive with a try/catch pair only causes a segfault, but 
> that's not the point anyway. What am I missing something here?

You're missing the fact that I forgot to implement this feature :-)  Fixed in 
SVN.

Re: Tuple literal syntax + Tuple assignment

[kenji hara]

2010年10月8日1:34 Andrei Alexandrescu :
> On 10/7/10 11:11 CDT, kenji hara wrote:
>> 2010/10/7 bearophile:
>>> Another design decision is if tuples have a nominative or structural type, 
>>> this problem comes out in this bug report:
>>> http://d.puremagic.com/issues/show_bug.cgi?id=4128
>>
>>> Another significant problem is about naming things, currently the situation 
>>> is a mess:
>>> http://www.digitalmars.com/d/archives/digitalmars/D/Tuple_TypeTuple_tupleof_etc_113005.html
>>> http://d.puremagic.com/issues/show_bug.cgi?id=4113
>>> In the end I have suggested to name "record" the typecons tuples, and 
>>> "tuple" the typetuples.
>>
>> On these issues, I'm almost agreed with bearophile
>>
>> I think we may not use 'Tuple' as 'a structure packed values'.
>> It is more better that 'Tuple' should *only* use as mixing sequence
>> types and values.
>
> The problem with this is that it departs from nomenclature that is
> agreed by everyone else, which is provincial.
>
> First off, a tuple IS agreed to be an ordered collection of
> heterogeneous items. Google reveals copious evidence, both in math and
> programming language theory.
>
> Benjamin Pierce's "Types and programming languages", a book that all PL
> students sleep with under their pillow, defines tuples in section 11.7
> (entitled "Tuples") like D does. The first paragraph:
>
> "It is easy to generalize the binary products of the previous section to
> n-ary products, often called tuples. For example, {1,2,true} is a
> 3-tuple containing two numbers and a Boolean. Its type is written
> {Nat,Nat,Bool}."
>
> The following section defines records as tuples with labeled fields. I
> don't think it's a crime that D calls both tuples. We could define
> Record just to be more Catholic than the Pope, but I don't see a
> necessity there. At any rate, "Tuple" is correct, known, understood, and
> accepted.

I understood that 'Tuple' is a generic word in math/language theory.
Withdraw my proposals.

> D's built in type tuples (those used with TypeTuple) are weird. They are
> an artifact of the language that has no meaning outside it. Such tuples
> are defined as "anything that could be a template parameter", which
> really ties them to various language design decisions. My suggestion is
> that we deprecate TypeTuple and we call it AliasTuple because that's
> really what it is - it's a tuple of stuff that can be passed in as an
> alias parameter.

It sounds for me that AliasTuple is a limited tuple contains only
alias parameters(exclude types).
I associate three kinds of template parameter (Type, Value, Alias)
with names '{Type|Value|Alias}Tuple'.
So I hope it will be called 'Tuple' in library, too.

(Given these, can I call std.typecons.Tuple ValueTyple?)

Thanks for your answer.

Kenji Hara

Re: Tuple literal syntax + Tuple assignment

[Michel Fortin]

On 2010-10-07 12:34:33 -0400, Andrei Alexandrescu 
 said:


My suggestion is that we deprecate TypeTuple and we call it AliasTuple 
because that's really what it is - it's a tuple of stuff that can be 
passed in as an alias parameter.


Personally, I like D built-in tuples; they're so simple. At the core 
they're just a group of "things". If you put only types in the tuple 
then it becomes usable as a type, and if you put only values in the 
tuple then it becomes usable as a value, and if I put variable 
declarations in the tuple then it becomes usable as a single variable 
aliased to all those variables, and if I mix all kind of things then 
it's just a heterogenous tuple that's probably only suitable as a 
template parameter.


Why should I know beforehand if I'm defining an alias tuple, a type 
tuple, a value tuple, or a whatever tuple? Seriously, the tuple is just 
a group of those "things" I put in it, and the compiler will tell me 
whenever I try to put that tuple where it doesn't belong.


Now, it sure would make sense to have a way to enforce whether a tuple 
is valid as a type or a valid as a value. But for many uses it isn't 
necessary, and it does simplify things to not have to care about it.


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

Re: "in" everywhere

[Daniel Gibson]

Steven Schveighoffer schrieb:
On Thu, 07 Oct 2010 10:09:17 -0400, Daniel Gibson 
 wrote:



Steven Schveighoffer schrieb:

On Thu, 07 Oct 2010 07:54:14 -0400, atommixz  wrote:

It would be nice if it were possible to use the "in" expression 
wherever

possible. Now it is only implemented for associative. arrays. (Weird).
Examples of how this could be used:
- Find string in string
- Search for a character in a string
- Search for an item in the array, array of characters, array of 
strings,

tuples, enum, structure
- what else?
 This has been suggested before.  The problem is that 'in' is 
generally considered to be a fast operation (< O(n)) so linear search 
is out.

 -Steve


Is it?
I wouldn't expect it to be < O(n) on a regular array, but it'd still 
be convenient to have instead of iterating over the array and 
comparing the contents yourself.


The problem is with generic code.  Generic code that accepts some type 
that defines the "in" operator.  What can that generic code expect for 
performance when using "in"?  As a general rule, generic programming 
must always assume the worst case, and if we have no rules for 'in', the 
worst case is linear.  Which means generic code may not use 'in' when it 
would be a fast operation.  Same thing with indexing.  Try sorting a 
'random access' range which uses a linear search on opIndex, and see 
what the performance is.


In addition, arr.find(x) seems pretty simple to me.

-Steve


I didn't know about arr.find(). Is that documented somewhere?

I do however agree that arr.find() is sufficient if it's there.

Cheers,
- Daniel

Re: Tuple literal syntax

[Walter Bright]

Ellery Newcomer wrote:
I might be missing something, but how does this proposal get around the 
ambiguity in


(a,b,c)[0]

?

Currently, it's valid C syntax and valid D syntax. In your proposal it 
would be valid tuple syntax too.


As has been proposed frequently, the , operator would have to be dispensed with.

Re: Tuple literal syntax

[Steven Schveighoffer]

On Thu, 07 Oct 2010 13:52:56 -0400, Walter Bright  
 wrote:



Ellery Newcomer wrote:
I might be missing something, but how does this proposal get around the  
ambiguity in

 (a,b,c)[0]
 ?
 Currently, it's valid C syntax and valid D syntax. In your proposal it  
would be valid tuple syntax too.


As has been proposed frequently, the , operator would have to be  
dispensed with.


I think what Ellery is alluding to is it breaks the rule that things that  
are valid C syntax do the same thing that happens in C.  Of course we've  
broken this rule a few times.


-Steve