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