Does D have too many features?

[foobar]

On Sunday, 29 April 2012 at 11:23:17 UTC, Timon Gehr wrote:
> 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 agree and indeed I haven't argued to remove break/continue from 
the language. Imperative style loops are already expressible with 
for/while/etc where break/continue work as advertizes. IMO a 
foreach loop is a higher level concept more suitable for 
functional style loops.
In any case, break/continue is implemented via opApply's return 
values and as such doesn't require anything special from the 
compiler to implement a library based foreach.


>
>> 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.
>

Well, I'll use a filter to filter out elements.... :)

> 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?

I discussed this many times in the past...
I don't really know haskell. But I do like ML.

>
>>>
>>>> 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.
>

A language is the interface between a human programmer and a 
computer and should IMO provide clear conceptual level 
abstractions for the benefit of the human. I realize that using 
enum for manifest constants makes sense on the implementation 
level but I feel the compiler should work for me and not the 
other way around.

>>>> [...]
>>>>
>>>> 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?
>>>
>
> ?

macro testMacro() {
  std.writeln("Hello world!");
  <| std.writeln("Hello world!"); |>
}

macro is a syntactic sugar on top of a regular function. You can 
call it just like you call a regular function. The first line is 
executed regularly and the second one is mixed-in [returned token 
stream from the macro]
since the macro is evaluated by the compiler, the first line 
would generate compile-time output. the second line would be part 
of the generated code and would be thus executed during run-time 
of my code.

Regarding syntax, the main difference is that it's a token stream 
and not text but otherwise pretty much the same as current CTFE. 
The important difference here is the execution model which is 
different from CTFE.

>
>>>
>>>> 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?

My example illustrates that the same considerations should be 
given to "compile-time" code as well as to the client application 
and it all depends on what you're trying to achieve.