Compiler hints, inlining and syntax consistency
Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang at gmail.com>
Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang at gmail.com>
Sat Dec 28 11:11:13 PST 2013
On Saturday, 28 December 2013 at 18:18:57 UTC, Jakob Ovrum wrote:
> algorithmic complexity requirements. If it makes the concept
> more palatable, you could instead imagine it as the anti-thesis
> of Java's collection interfaces.
Anything that isn't Java sounds palatable… Except for
Objective-C, which is worse.
> However, it should be noted that D supports flexible
> metaprogramming which has resulted in algorithms with looser
> requirements, such as Andrei's
> `std.algorithm.levenshteinDistance` which doesn't require
> random access, circumventing the problem entirely.
Nice. Yes, that kind of illustrate the real issue, what you
really want in the ideal world is to specify the basic properties
of your dataset and the algorithms you want to apply to it. Then
let the compiler choose the best fit in the available set of
container- and algorithm- implementations. (or achieve the same
through profiling)
But that is kind of difficult to achieve for library level ADTs
with just basic templates, so the algorithm implementor has to
predict usage patterns instead.
> But the disadvantages are serious, most notably generic code
> that uses `in` and assumes it has some complexity guarantee
> would experience a blow-up in complexity when an array is
> passed.
Ok, I agree with this for simple operators like +, -, * etc.
Whether 'in' is a simple operator probably depends on what you
are used to from other languages.
> Further, adding syntax sugar to such an operation sends the
> wrong signal and is thus asking for trouble during code
> maintenance - initially the array might have been small and use
> of `in` judicious, but later down the line the array grows
> while the use of `in` is preserved because it *looks* low-cost
Depends on where you come from. I think it is quite common in
Python code to test 'in' for short immutable (literal) arrays,
e.g. "if action in ['say','talk','shout']:"
I think it is reasonable to accept that, because the code becomes
much easier to read if you do lots of text processing. So it
depends on what kind of programs you tend to write. It has no
place in a 3D engine, but is useful in text based adventure games.
More information about the Digitalmars-d
mailing list