Walter Bright wrote:
> The compiler is nowhere near ready to implement parallel stuff. But when it is, I'd like to try doing it automatically before inventing more syntax for it.
I added the syntax mostly so the user had some way of specifying to container classes that an unordered operation should be used. But I do agree that adding syntax is never a good thing if other options are available.
Sean

Oskar Linde wrote:
> Bill Baxter wrote:
> >> Oskar Linde wrote:
>>>>> Walter Bright wrote:
>>>>>>> Bill Baxter wrote:
>>>>>>>>>> foreach(x; "abcd".reverseView())
>>> writef("%s",x);
>>>>>> prints "dcba"
>>>>>> For any type of built in array for a very long time (long before 0.170), and it certainly seems to work for me.
>>>>>> How do you do that? I just get
>> : undefined identifier reverseView
>> : function expected before (), not reverseView of type int
>> : cannot infer type for x
> > > Sorry. I wasn't very clear on this in my post. Here is a simple implementation that runs:
> ...
Ok, I see. Yeh, I just yesterday learned about this trick of defining methods for array classes (after I sent the message). It's very well hidden in the spec. ;-) Thanks for taking the time to make that example.
--bb

Ivan Senji wrote:
> BCS wrote:
>> no, all you really need is goto and label variables
>>>> int i = 10;
>> loop:
>> i--;
>> goto [loop, quit][cast(int)(i==0)];
>> quit:
> > But this doesn't work, you can't create an array of label names.
Read carefully. What he said was "all you really need is goto and label variables".
The fact we can't /currently/ do it this (because we don't have the latter of the two) doesn't mean he's wrong ;).

Walter Bright wrote:
> Oskar Linde wrote:
>> It could also simplify the core language.
> > > foreach_reverse was pretty trivial to implement. All the machinery was already there.
> >> What is design if not the pursuit of simplicity?
> > > Simplicity is sometimes an elusive goal. For example, D started out with a simple syntax for function literals. Nobody used it, nobody even noticed it, people kept asking for the feature even after I pointed it out to them that D had it. Then, I figured out a way to eliminate some of the extra syntax for it, and voila! suddenly it gets noticed. This is even though the newer style is harder to parse and implement.
> > I also remember a thread here about D versus Ruby, and how everything was so simple in Ruby. It didn't matter that I showed how it could be done in D, it appeared to be simpler in Ruby, and that apparently made all the difference.
Definitely. Simplicity of the language and simplicity of the implementation are NOT the same thing. What matters most to USERS is the the conceptual simplicity of the language itself. Not how many hoops the compiler writer had to jump thorugh to make it look simple. Sometimes a simple conceptual model goes hand-in-hand with simple implementation. Sometimes it doesn't. A good example of the former is Scheme. A good example of the latter is maybe Boost::Spirit, to pick an example from recent discussion, though it doesn't do that great a job of appearing simple (but much simpler than the underlying implementation).
A better example is probably pure OO languages that make everything an object, including things like number literals.
The thing to strive for is a simple conceptual model.
Hmm, rereading this though, I think you'd argue that you didn't change or simplify any "concepts" you just changed syntax. Could be. But I think there is a connection between the two. Clumsy syntax can cloud the underlying clarity of the concepts. Just like the boost::spirit parser,
real_p >> *(char_p(',') >> real_p)
is the same thing as EBNF
real (',' real)*
but one makes the concept a lot easier to see than the other.
Also -- and I think you've noted this before yourself -- end users often go for local optimizations. In the short term they want a fix to the immediate problem they see. But that's not a good way to design a language. You want the global optimum.
--bb

Walter Bright wrote:
> Oskar Linde wrote:
> >> Walter Bright wrote:
>>>>> Bill Baxter wrote:
>>>>>>> I don't see how it helps. If you can already do:
>>>> foreach(T item; &collection.reversed()) { }
>>>>>>>>> That doesn't work for arrays.
>>>>>> In what way does it not work? I have been doing:
>>>> foreach(x; "abcd".reverseView())
>> writef("%s",x);
>>>> prints "dcba"
> > > Try that, along with foreach_reverse, and look at the generated code.
Hmm. So that's the main issue then, is it? To have a reverse iteration on arrays that's as close to a hand-written for-loop as possible?
If you could only think of some way to automatically optimize that case to generate the same code... Is it totally hopeless?
--bb

Bill Baxter wrote:
> Hmm. So that's the main issue then, is it? To have a reverse iteration on arrays that's as close to a hand-written for-loop as possible?
The major issue is that foreach will usually be used on arrays, and it had better produce good code for them, or else people will eshew it and stick with for.
> If you could only think of some way to automatically optimize that case to generate the same code... Is it totally hopeless?
Trying to recognize it out of an opApply is rather difficult.

Bill Baxter wrote:
> Also -- and I think you've noted this before yourself -- end users often go for local optimizations. In the short term they want a fix to the immediate problem they see. But that's not a good way to design a language. You want the global optimum.
Sure. But in the year and a half since the long thread proposing foreach_reverse and various alternatives, nothing better has come up. foreach_reverse gets the job done in a simple, understandable, and efficient manner.