View mode: basic / threaded / horizontal-split · Log in · Help
October 18, 2006
Re: DMD 0.170 release
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.
October 18, 2006
Re: DMD 0.170 release
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
October 18, 2006
Re: DMD 0.170 release
BCS wrote:
> Walter Bright wrote:
>> Stewart Gordon wrote:
>>
>>> Vladimir Kulev wrote:
>>>
>>>> J Duncan wrote:
>>>>
>>>>> Disagree with you, its a nice thing to have.
>>>>
>>>>
>>>> There are many things which are nice to have, but only really 
>>>> essential ones
>>>> should be in language itself. Reverse foreach can be implemented in 
>>>> other
>>>> way.
>>>
>>>
>>> So can ordinary foreach.
>>
>>
>> All you really need is if and goto!
> 
> 
> 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.
October 18, 2006
Re: DMD 0.170 release
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
October 18, 2006
Re: DMD 0.170 release
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 ;).
October 18, 2006
Re: DMD 0.170 release
Frits van Bommel wrote:
> 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 ;).

Look, look, I really should have read more carefully, thanks :)
October 18, 2006
Re: DMD 0.170 release
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
October 18, 2006
Re: DMD 0.170 release
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
October 18, 2006
Re: DMD 0.170 release
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.
October 19, 2006
Re: DMD 0.170 release
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.
7 8 9 10 11 12 13 14 15
Top | Discussion index | About this forum | D home