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?
