Bill Baxter wrote:
> Andrei Alexandrescu (See Website For Email) wrote:
> 
> 
>> I'm actually mildly surprised. Lately there was some talk around here about supporting the day-to-day programmers and so on. I find looping a very day-to-day thing, and looping over 2+ things at least a few-days-to-few-days thing. There is a need for parallel iteration, if nothing else shown by the existence of a library that addresses exactly that - to the extent possible in a library that's not in the position to control syntax, scoping, and visibility. I was sure people will be on this one like white on rice. But Bjarne Stroustrup was right: nobody knows what most programmers do :o).
> 
> Python and Ruby are hardly considered to be obtuse languages, or unfriendly to Joe coder, but both get by just fine without special case syntax for iterating over multiple collections, or for iterating in reverse.
>    for x,y izip(foo,bar):
>        do stuff
> 
>    for x reversed(foo):
>        do stuff
> 
>    for x,y izip(reversed(foo),bar):
>        do that with your proposal!

foreach (x ; reverse_view(foo)) (y ; bar)
  probably I could!

> That said, I understand that Python and Ruby have a little more freedom to pile up the abstractions because both of them are so friggin slow that a few more layers won't hurt anything.  D can't be quite so cavalier about tossing performance for elegance.

Yah. Costly abstractions are a dime a dozen.

> Still, I'm remain unconvinced that D can't have both performance and elegance.

Macros will get us closer to that.


Andrei

Andrei Alexandrescu (See Website For Email) wrote:
> Bill Baxter wrote:
>> Andrei Alexandrescu (See Website For Email) wrote:
>>
>>
>>> I'm actually mildly surprised. Lately there was some talk around here about supporting the day-to-day programmers and so on. I find looping a very day-to-day thing, and looping over 2+ things at least a few-days-to-few-days thing. There is a need for parallel iteration, if nothing else shown by the existence of a library that addresses exactly that - to the extent possible in a library that's not in the position to control syntax, scoping, and visibility. I was sure people will be on this one like white on rice. But Bjarne Stroustrup was right: nobody knows what most programmers do :o).
>>
>> Python and Ruby are hardly considered to be obtuse languages, or unfriendly to Joe coder, but both get by just fine without special case syntax for iterating over multiple collections, or for iterating in reverse.
>>    for x,y izip(foo,bar):
>>        do stuff
>>
>>    for x reversed(foo):
>>        do stuff
>>
>>    for x,y izip(reversed(foo),bar):
>>        do that with your proposal!
> 
> foreach (x ; reverse_view(foo)) (y ; bar)
>   probably I could!

foreach (x,y ; transpose_view(reverse_view(foo),bar)
  then why not this too?!

--bb

Bill Baxter wrote:
> Andrei Alexandrescu (See Website For Email) wrote:
>> Bill Baxter wrote:
>>> Andrei Alexandrescu (See Website For Email) wrote:
>>>
>>>
>>>> I'm actually mildly surprised. Lately there was some talk around here about supporting the day-to-day programmers and so on. I find looping a very day-to-day thing, and looping over 2+ things at least a few-days-to-few-days thing. There is a need for parallel iteration, if nothing else shown by the existence of a library that addresses exactly that - to the extent possible in a library that's not in the position to control syntax, scoping, and visibility. I was sure people will be on this one like white on rice. But Bjarne Stroustrup was right: nobody knows what most programmers do :o).
>>>
>>> Python and Ruby are hardly considered to be obtuse languages, or unfriendly to Joe coder, but both get by just fine without special case syntax for iterating over multiple collections, or for iterating in reverse.
>>>    for x,y izip(foo,bar):
>>>        do stuff
>>>
>>>    for x reversed(foo):
>>>        do stuff
>>>
>>>    for x,y izip(reversed(foo),bar):
>>>        do that with your proposal!
>>
>> foreach (x ; reverse_view(foo)) (y ; bar)
>>   probably I could!
> 
> foreach (x,y ; transpose_view(reverse_view(foo),bar)
>   then why not this too?!

Because it doesn't keep bound variables together with the data. Perl has a way of initializing multiple variables that is unnerving:

my ($a, $b, $c) = (e1, e2, e3);

The long-distance relationships make it so irritating when ek are more than a couple of characters, I often give up and write:

my $a = e1;
my $b = e2;
my $c = e3;

even though I try to use vertical space sparingly.


Andrei

Andrei Alexandrescu (See Website For Email) wrote:
> Bill Baxter wrote:
>> Andrei Alexandrescu (See Website For Email) wrote:
>>> Bill Baxter wrote:
> 
> Because it doesn't keep bound variables together with the data. Perl has a way of initializing multiple variables that is unnerving:
> 
> my ($a, $b, $c) = (e1, e2, e3);
> 
> The long-distance relationships make it so irritating when ek are more than a couple of characters, I often give up and write:
> 
> my $a = e1;
> my $b = e2;
> my $c = e3;
> 
> even though I try to use vertical space sparingly.
> 
> 
> Andrei

IMO, the original version that you've suggested looks best.  I can't see any way of improving the syntax.  Well maybe the continue part could be improved, like:

foreach (i ; coll1) (j ; coll2)
{
  ... use i and j ...
}
continue(i)
{
  ... coll2 finished; use i ...
}
continue(j)
{
  ... coll1 finished; use j ...
}

Or perhaps a word like "finish" would be better.

-Joel

Andrei Alexandrescu (See Website For Email) napisał(a):
> James Dennett wrote:
>> C++, of course, has std::for_each(e.begin(), e.end(), do_x);
>> in its library (though that's weaker than it could be because
>> of lack of support for convenient anonymous functions/lambdas).
>>
>> C++0x is very likely to have for(v: e).  It's implemented
>> in ConceptGCC already. Java already has essentially that,
>> as does C#.  This really doesn't set D apart (but at least
>> D isn't falling behind here).
> 
> BTW, D might soon have simultaneous iteration that will blow away all conventional languages:
> 
> foreach (i ; coll1) (j ; coll2)
> {
>   ... use i and j ...
> }
> continue foreach (i)
> {
>   ... coll2 finished; use i ...
> }
> continue foreach (j)
> {
>   ... coll1 finished; use j ...
> }
> 
> Best languages out there are at best ho-hum when it comes about iterating through simultaneous streams. Most lose their elegant iteration statement entirely and come with something that looks like an old hooker early in the morning.
> 
> 
> Andrei

Isn't it possible to extend proposed syntax for something like suggested on D wish list:

http://all-technology.com/eigenpolls/dwishlist/index.php?it=42

---
In short: there is a proposition to add special cases in 'foreach' for first iterated element and last element. It could allow use of 'foreach' also for cases like

char[] arr = ["a", "b", "c"];
char[] res;
for(int i=0; i<arr.length-1; i++) {
	res~=arr[i] ~ ",";
}
if (arr.length>0) res~=arr[$-1];

into something like this (just raw proposition - syntax might by different):

foreach(e; arr) {
res~=e ~ ",";
}
last foreach(e) {
res~=e;
}

It seems that it would be logical consequence of proposed syntax... And would be very useful as above use case is quite popular IMHO.

Best Regards
Marcin Kuszczak

Aarti_pl napisał(a):
> Andrei Alexandrescu (See Website For Email) napisał(a):
>>
>> foreach (i ; coll1) (j ; coll2)
>> {
>>   ... use i and j ...
>> }
>> continue foreach (i)
>> {
>>   ... coll2 finished; use i ...
>> }
>> continue foreach (j)
>> {
>>   ... coll1 finished; use j ...
>> }
>>
> 
> Isn't it possible to extend proposed syntax for something like suggested on D wish list:
> 
> http://all-technology.com/eigenpolls/dwishlist/index.php?it=42
> 
> ---
> In short: there is a proposition to add special cases in 'foreach' for first iterated element and last element. It could allow use of 'foreach' also for cases like
> 
> char[] arr = ["a", "b", "c"];
> char[] res;
> for(int i=0; i<arr.length-1; i++) {
>     res~=arr[i] ~ ",";
> }
> if (arr.length>0) res~=arr[$-1];
> 
> into something like this (just raw proposition - syntax might by different):
> 
> foreach(e; arr) {
> res~=e ~ ",";
> }
> last foreach(e) {
> res~=e;
> }
> 
> It seems that it would be logical consequence of proposed syntax... And would be very useful as above use case is quite popular IMHO.
> 
> Best Regards
> Marcin Kuszczak

Maybe syntax like this would be more D-ish, flexible and compact, because in fact we need kind of switch..case syntax for 'foreach'... :

foreach (i ; coll1) (j ; coll2) {
	  ... use i and j ...

	case(continue)(i) {
	  ... coll2 finished; use i ...
	}

	case(continue)(j) {
	  ... coll1 finished; use j ...
	}

	case(last)(i) {
	  ... do something with last col1 element
	}

	case(first)(j) {
	  ... do something with first col2 element
	}
}

It does not introduce new keywords and is easy to extend for other situations. I like also that everything is a part of foreach, and is not separated into different statements...

BR
Marcin Kuszczak

Kevin Bealer wrote:
> 
> Actually, I can understand the structure in both languages for this simple example without too much trouble.  But the LISP one is a lot 'slower' for me to scan with my eyes.  Some of that is a learned reflex, of course, but personally I don't think all of it is.
> 
> My point is less about indentation than the other aspects of syntax. For one thing, the '(){};,' punctuation, which for me, is a win over the LISP way (again, assuming both examples are indented).  If the LISP syntax is readable for you throughout, then that's okay.  For me it definitely isn't -- I think most people would agree.

I certainly see your point and accept it.

I think its worth noting the Lisp 'if' isnt neccasarily the same as the C like one though, I suppose its closer actually to the ternary operator. This lisp expression:

(quite possibly the indentation will screw again in which case Im sorry)

(let ((k (if (if (zerop x)
	       (foo 100)
	     (bar 100))
	   (zen 30)
	 (wibble q)))))

would be like this C (I think!):

k = ((x == 0) ? foo(100) : bar(30)) ? zen(30) : wibble(q));

Using the structured C 'if' you get:

int t;
if(x == 0)
  t = foo(100);
else
  t = bar(100);

int k
if(t)
  k = zen(30);
else
  k = wibble(q);

I prefer the Lisp, the ternary version is bizarre to read and the structured if version fails to properly show how the first if expression controls the second, you have to memorize (and use for that matter) the temporary variable which represents the nested expression.

Regarding how its useful to have different bracket types to delimit the layout, I think thats a decent point, Im pretty sure there is an editor mode which colours each nested level of parans a different colour I think that would acheive a similar thing.

> 
> Someone I know at work told me today that the LISP notation is very much like mathematical formulas.  I couldn't help remembering math classes in college, when (at the time) I was always thinking, 'why can't they break this up into simple steps like a computer program would?'  (Of course, I learned a lot about programming before I took algebra, so maybe that's part of the problem.)

Its an interesting observation, I learnt algebra before computer programming and also learnt computer programming without a specific language. My introduction to Computer Science was entirely theoretical; we learnt all about computers and programming without ever actually touching a computer (seems kinda bizarre now I think about it - we did have computers!) I didnt start programming seriously until after I left school. My first practical programming experience was Sinclair Basic, then some Lispish language on a programmable calculator, then Zortech C. I always prefered to write math formulas in something like Lisp (ie prefix, no precedence rules, no funky math syntax) my teachers hated it. When I first tried to learn C it took me ages to get my head around all the different bits of syntactic sugar, precedence rules and unexpected corner cases. I dont have a problem with that now but certainly if I do have something mathematical to write or a complicated algorithm to devise I often sketch it out in Lispish form first or fire up Lisp and program until I get an understanding of how its going to work before starting the C++.

Bunny

I waited a long time to reply to this thread and I didn't read the latest (let's guess, 60) messages replied to this thread because lots of them where about LISP and of about how people think (recursively or not).

So why do I reply then? Because all this discussion about mixins and all this stuff makes me a bit sad. I don't like it as well as I don't like the C++ macros (and everyone on the #d channel knows that I really _hate_ them...).

The main problem I have with mixins/templates and so on is that it
enables a programmer to change the "look and feel" of the language
completely. What is bad about it? That if you're working in a team
someone has a "great idea" and invents his own MyDSL. So what? Everyone
else has to "learn" this new DSL. So they spend time on something they
would've better spent on coding something else, or fixing bugs... I
worked in a team of about 8 persons bugfixing a project with
approximately 1.000.000 LoC. The former programmers just seemed to not
know how to code (and we programmed using Delphi!!! a language most
people like to tell you: "oh, that's a language that shows you how to
work structured" - that's totally bullshit!).
So on one hand, we had to improve the software as it was used by just
too many companies to completely rewrite it - on the other hand we had
to bugfix it with a syntax that even didn't look like Pascal. Now what?
If we had someone "just for the sake of it" implementing something with
his MyDSL, i would've probably killed him!

The thing I really want to say is: Stick to a clear definition on what the language is, and what not. As long as I can remember - for example - working on a python project was as easy as possible, because the language just defined what is "and what not". If you let the programmer decide and how to extend the language (and this is definitely possible with templates and mixins and macros and the whole bunch of shitload).

Okay, there are some examples (even provided by Walter) on how to properly use mixins and templates (for example letting the compiler generate the byte-array for an icon file), but there's always someone who thinks how "smart" he is and invents something that's just time consuming to learn...

I think, that even templates are used too much at the moment (have a look at tango, that's full of this). Why? because it doesn't fit into the OOP pragma - you would've used some interface declarations and then invented some functions that work on the interfaces instead of writing a template... But well, there are some cases where templates are just nice.

I would really like to see more of the "details" implemented (runtime type information, for example, or something like delphi's "type TClass = class of TObject" to make it possible to create correct Object Factories) instead of the new language features we got with the last few releases.

I had a look at D because it was C++ just without all this stuff I didn't like, but with the new language features, C++'s bad stuff is simply replaced by something else that will definitely be used in the wrong way (have a look at the apache headers, for example. macros&macros&macros&...)

I really hope you will guide the D language into the right direction, because I do like the language, but unfortunately, I don't like the newest language features.

Best regards,
Nicolai

Nicolai Waniek wrote:
> I waited a long time to reply to this thread and I didn't read the
> latest (let's guess, 60) messages replied to this thread because lots of
> them where about LISP and of about how people think (recursively or not).
> 
> So why do I reply then? Because all this discussion about mixins and all
> this stuff makes me a bit sad. I don't like it as well as I don't like
> the C++ macros (and everyone on the #d channel knows that I really
> _hate_ them...).
> 
> The main problem I have with mixins/templates and so on is that it
> enables a programmer to change the "look and feel" of the language
> completely. What is bad about it? That if you're working in a team
> someone has a "great idea" and invents his own MyDSL. So what? Everyone
> else has to "learn" this new DSL. So they spend time on something they
> would've better spent on coding something else, or fixing bugs... I
> worked in a team of about 8 persons bugfixing a project with
> approximately 1.000.000 LoC. The former programmers just seemed to not
> know how to code (and we programmed using Delphi!!! a language most
> people like to tell you: "oh, that's a language that shows you how to
> work structured" - that's totally bullshit!).
> So on one hand, we had to improve the software as it was used by just
> too many companies to completely rewrite it - on the other hand we had
> to bugfix it with a syntax that even didn't look like Pascal. Now what?
> If we had someone "just for the sake of it" implementing something with
> his MyDSL, i would've probably killed him!
> 
> The thing I really want to say is: Stick to a clear definition on what
> the language is, and what not. As long as I can remember - for example -
> working on a python project was as easy as possible, because the
> language just defined what is "and what not". If you let the programmer
> decide and how to extend the language (and this is definitely possible
> with templates and mixins and macros and the whole bunch of shitload).
> 
> Okay, there are some examples (even provided by Walter) on how to
> properly use mixins and templates (for example letting the compiler
> generate the byte-array for an icon file), but there's always someone
> who thinks how "smart" he is and invents something that's just time
> consuming to learn...
> 
> I think, that even templates are used too much at the moment (have a
> look at tango, that's full of this). Why? because it doesn't fit into
> the OOP pragma - you would've used some interface declarations and then
> invented some functions that work on the interfaces instead of writing a
> template... But well, there are some cases where templates are just nice.
> 
> I would really like to see more of the "details" implemented (runtime
> type information, for example, or something like delphi's "type TClass =
> class of TObject" to make it possible to create correct Object
> Factories) instead of the new language features we got with the last few
> releases.
> 
> I had a look at D because it was C++ just without all this stuff I
> didn't like, but with the new language features, C++'s bad stuff is
> simply replaced by something else that will definitely be used in the
> wrong way (have a look at the apache headers, for example.
> macros&macros&macros&...)
> 
> I really hope you will guide the D language into the right direction,
> because I do like the language, but unfortunately, I don't like the
> newest language features.
> 
> Best regards,
> Nicolai

What about using it for files that you are going to load at runtime otherwise? XML ect...?

-Joel

janderson wrote:
> Nicolai Waniek wrote:
>> I waited a long time to reply to this thread and I didn't read the
>> latest (let's guess, 60) messages replied to this thread because lots of
>> them where about LISP and of about how people think (recursively or not).
>>
>> So why do I reply then? Because all this discussion about mixins and all
>> this stuff makes me a bit sad. I don't like it as well as I don't like
>> the C++ macros (and everyone on the #d channel knows that I really
>> _hate_ them...).
>>
>> The main problem I have with mixins/templates and so on is that it
>> enables a programmer to change the "look and feel" of the language
>> completely. What is bad about it? That if you're working in a team
>> someone has a "great idea" and invents his own MyDSL. So what? Everyone
>> else has to "learn" this new DSL. So they spend time on something they
>> would've better spent on coding something else, or fixing bugs... I
>> worked in a team of about 8 persons bugfixing a project with
>> approximately 1.000.000 LoC. The former programmers just seemed to not
>> know how to code (and we programmed using Delphi!!! a language most
>> people like to tell you: "oh, that's a language that shows you how to
>> work structured" - that's totally bullshit!).
>> So on one hand, we had to improve the software as it was used by just
>> too many companies to completely rewrite it - on the other hand we had
>> to bugfix it with a syntax that even didn't look like Pascal. Now what?
>> If we had someone "just for the sake of it" implementing something with
>> his MyDSL, i would've probably killed him!
>>
>> The thing I really want to say is: Stick to a clear definition on what
>> the language is, and what not. As long as I can remember - for example -
>> working on a python project was as easy as possible, because the
>> language just defined what is "and what not". If you let the programmer
>> decide and how to extend the language (and this is definitely possible
>> with templates and mixins and macros and the whole bunch of shitload).
>>
>> Okay, there are some examples (even provided by Walter) on how to
>> properly use mixins and templates (for example letting the compiler
>> generate the byte-array for an icon file), but there's always someone
>> who thinks how "smart" he is and invents something that's just time
>> consuming to learn...
>>
>> I think, that even templates are used too much at the moment (have a
>> look at tango, that's full of this). Why? because it doesn't fit into
>> the OOP pragma - you would've used some interface declarations and then
>> invented some functions that work on the interfaces instead of writing a
>> template... But well, there are some cases where templates are just nice.
>>
>> I would really like to see more of the "details" implemented (runtime
>> type information, for example, or something like delphi's "type TClass =
>> class of TObject" to make it possible to create correct Object
>> Factories) instead of the new language features we got with the last few
>> releases.
>>
>> I had a look at D because it was C++ just without all this stuff I
>> didn't like, but with the new language features, C++'s bad stuff is
>> simply replaced by something else that will definitely be used in the
>> wrong way (have a look at the apache headers, for example.
>> macros&macros&macros&...)
>>
>> I really hope you will guide the D language into the right direction,
>> because I do like the language, but unfortunately, I don't like the
>> newest language features.
>>
>> Best regards,
>> Nicolai
> 
> What about using it for files that you are going to load at runtime otherwise? XML ect...?

I don't personally see this as much of a benefit.  Most applications have long run times, and spending a fraction of a second loading files on application start simply isn't a big deal.  Certainly not enough of one to invent a new language feature for it.


Sean