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.

On Saturday, 28 December 2013 at 19:11:14 UTC, Ola Fosheim Grøstad wrote:
>> 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.

That's fair enough. I think the safe choice is to wait and see how it unfolds in libraries to come.

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

For array literals it's not such a bad idea, and was recently topical in the assessment of `std.algorithm.among`[1]. However, as elaborated upon in the linked PR, I think the library solution is superior for D.

[1] https://github.com/D-Programming-Language/phobos/pull/1787

On Saturday, 28 December 2013 at 19:20:15 UTC, Jakob Ovrum wrote:
> For array literals it's not such a bad idea, and was recently topical in the assessment of `std.algorithm.among`[1]. However,

It is not a bad idea for sorted arrays either, when you think about it: O(log n)

On Saturday, 28 December 2013 at 19:24:19 UTC, Ola Fosheim Grøstad wrote:
> On Saturday, 28 December 2013 at 19:20:15 UTC, Jakob Ovrum wrote:
>> For array literals it's not such a bad idea, and was recently topical in the assessment of `std.algorithm.among`[1]. However,
>
> It is not a bad idea for sorted arrays either, when you think about it: O(log n)

It could be added to `std.range.SortedRange`. For element type T, it could return T* when the underlying range has write access, and bool otherwise.

SortedRange needs work anyway; for one, I always wanted `find` on a sorted range to do binary search seamlessly...

On 2013-12-28 16:36, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang@gmail.com>" wrote:

> Understand. Objective-C and Python also suffers from the arbitrary "@"
> syntax.

I don't think Objective-C suffers from this. In Objective-C @ is used for every new keyword and other stuff that's not available in standard C. Sure, you can do all that in plain C but it's very cumbersome and verbose.

-- 
/Jacob Carlborg

On 2013-12-28 16:40, Dicebot wrote:

> Usage of "@" for new keywords is just a matter of avoiding name clashes
> with existing user code.

That worked until we got UDA's with the same syntax.

-- 
/Jacob Carlborg

On Saturday, 28 December 2013 at 18:55:31 UTC, Chris Cain wrote:
> Same usage, `someGenericAlgorithm(assumeWalkLengthOK(myContainer));` (I didn't actually run this through dmd, but it should work in theory)

Not too bad. Being able to create adaptors like this is a nice workaround for overruling library design decisions, at least if it is simple enough for the compiler backend is able to "undo" any overhead.

On Saturday, 28 December 2013 at 20:07:46 UTC, Jacob Carlborg wrote:
> I don't think Objective-C suffers from this. In Objective-C @ is used for every new keyword and other stuff that's not available in standard C.

Yes, well what I meant was that they used @ to avoid keyword clashes with the existing grammar. I personally feel like I am suffering when using Objective-C, it's like talking to a compiler with a split personality disorder.

On Saturday, 28 December 2013 at 20:09:36 UTC, Jacob Carlborg wrote:
> On 2013-12-28 16:40, Dicebot wrote:
>
>> Usage of "@" for new keywords is just a matter of avoiding name clashes
>> with existing user code.
>
> That worked until we got UDA's with the same syntax.

I have deja vu - remember talking with you about exactly this topic in NG several months ago :) (My point was that it will still work if we make built-in attributes qualified with a reserved module name which is backwards-compatible change)

On 2013-12-28 22:07, Dicebot wrote:

> I have deja vu - remember talking with you about exactly this topic in
> NG several months ago :)

Perhaps :)

> (My point was that it will still work if we
> make built-in attributes qualified with a reserved module name which is
> backwards-compatible change)

And my answer to that was probably something like: that module name could already be in use today. Also, then we get a third way of naming keywords:

@property nothrow @reserved.foobar int bar ();

-- 
/Jacob Carlborg