Does D have too many features?
foobar
foo at bar.com
Sun Apr 29 02:31:43 PDT 2012
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. How often do you use
these features anyway in your regular code? 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..
I'll use these constructs in a for loop but not a foreach loop.
>
>>>
>>>> * 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.
>
>> 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.
>>[...]
>>
>> 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. If you only use a batch mode compiler
you can simply kill the process which btw applies just the same
to your user program. However, if you use an integrated compiler
in your IDE that could cause me to lose part of my work if the
IDE crashes.
More information about the Digitalmars-d
mailing list