Does D have too many features?

[Timon Gehr]

On 04/29/2012 11:31 AM, foobar wrote:
> On Sunday, 29 April 2012 at 08:58:24 UTC, Timon Gehr wrote:
>>> [...]
>>> Indeed but I'd go even further by integrating it with ranges so that
>>> ranges would provide an opApply like method e.g.
>>> auto r = BinaryTree!T.preOrder(); // returns range
>>> r.each( (T elem) { ...use elem...}); // each method a-la Ruby
>>>
>>
>> Well, I don't think this is better than built-in foreach (with full
>> break and continue and goto even for user-defined opApply!)
>
> I think we reached a matter of taste here.

Certainly, and this applies to the other issues as well.

> How often do you use these features anyway in your regular code?

Not too often, but it is awesome that it actually works. ;)

> I prefer a more functional style
> with higher order functions (map/reduce/filter/etc..) so for me foreach
> is about applying something to all elements and doesn't entail usage of
> break/continue/etc..

Some algorithms are better expressed in functional terms, some 
algorithms are better expressed in imperative terms. I think a 
combination of the two usually is the best choice.

> I'll use these constructs in a for loop but not a foreach loop.
>

break can be used as an optimisation to stop execution of a loop that 
performs a 'reduce' if the result cannot change after a certain point. I 
use continue mostly for 'filter'-ing out elements from consideration.

Usually there is not a huge difference between imperative style and 
functional style loops.

>>
>>>>
>>>>> * enum - enum should be completely redesigned to only implement
>>>>> what it's named after: enumerations.
>>>>>
>>>>
>>>> What is the benefit?
>>>
>>> On the one hand the current enum for manifest constants is a hack due to
>>> weaknesses of the toolchain
>>
>> I think that is actually not true. It might have been the original
>> motivation, but it has gone beyond that. Which weaknesses in
>> particular? I don't think that the toolchain can be improved in any
>> way in this regard.
>
> The weakness as far as I know is about link time optimization of constants.
> But regardless, my ideal implementation of so called "compile-time"
> features, including compile time constants, would be very different anyway.
>

Well, you never elaborate on these things. BTW, what is your stance on 
template haskell?

>>
>>> and on the other hand it doesn't provide
>>> properly encapsulated enums
>>
>> Those could in theory be added without removing the manifest constant
>> usage.
>>
>>> such as for instance the Java 5.0 ones or
>>> the functional kind.
>>>
>>
>> An algebraic data type is not an 'enumeration', so this is a moot point.
>
> I disagree. They are a generalization of the concept. In fact,
> functional languages such as ML implement c style enums as an algebraic
> data type.
>

The current way enums can be used as manifest constants is a 
generalization as well. The generalization takes place on the static 
semantics level instead of on the conceptual level though.


>>> [...]
>>>
>>> I should be able to use a *very* minimalistic system to write completely
>>> _regular_ D code and run it at different times.
>>
>> Examples in concrete syntax? How would you replace eg. string mixin
>> functionality?
>>

?

>>
>>> This is a simple matter
>>> of separation of concerns: what we want to execute (what code) is
>>> separate to the concern of when we want to execute it.
>>>
>>
>> It is not. For example, code that is only executed during CTFE does
>> never have to behave gracefully if the input is ill-formed.
>
> I disagree - you should make sure the input is valid or all sorts of bad
> things could potentially happen such as a compiler can get stuck in an
> infinite loop.

It could fail in a number of other ways. I don't think that this example 
can be used to invalidate the statement.

> If you only use a batch mode compiler you can simply kill
> the process which btw applies just the same to your user program.

Maybe the user program should not be killed. See your IDE example.

> However, if you use an integrated compiler in your IDE that could cause
> me to lose part of my work if the IDE crashes.

Why would the IDE crash?