Hacker News Reader

Comment by logicchains | Hacker News Reader

>so tired of having to hunt down what functions are going to return, sometimes having to resort to just using it

With highly generic functions, it's often not possible to know what they'll return without knowing what you'll call them with. Especially given that D functions like "map" and "reduce" tend to return special iterator types so that the compiler is able to smarty fuse them where possible. If D had concepts like C++20, you could probably describe them with something looking like:

    template<class R>
    
      concept __SimpleView =                         //     exposition only
        ranges::view<R> && ranges::range<const R> &&
        std::same_as<std::ranges::iterator_t<R>, std::ranges::iterator_t<const R>> &&
        std::same_as<std::ranges::sentinel_t<R>, std::ranges::sentinel_t<const R>>;

But at least for me that doesn't seem like it would be much more helpful than just reading the documentation, which states what the function returns, if not necessarily the type.

View on HN

So you still can see that it depends on some input. That is hugely more useful then auto.

>With highly generic functions, it's often not possible to know what they'll return without knowing what you'll call them with.

Of course it is. Map's type is "(a -> b) -> [a] -> [b]". D just absolutely and completely failed here, despite this being a solved problem 40 years ago.

It doesn't have to be specialized to []

Of course not. But it still has a type.

Functor f => (a -> b) -> f a -> f b

no ? there are plenty of maps which don't return something which looks like [a] -> [b].

So? They still have a type, it doesn't have to be "screw you figure it out yourself".

Functor f => (a -> b) -> f a -> f b

Repeating the same over and over again doesn't make it any clearer for the ones trying to follow your line of argumentation.

Seems like you had some deep exposure to Haskell, ML or Hindley-Milner in general which, when excessively consumed, detaches from reality.

For one reason or the other you take this discussion serious and personal.

If something is unclear, you can ask for clarification. I repeated the statement to three people because three people repeated the same argument to me. This is how conversations work. I have very limited exposure to haskell, am not detached from reality, and am taking nothing personal. Of course the discussion is serious, why would I spend time engaging in a frivolous and meaningless discussion?

could you provide the type of this map function ?

    auto map(auto x) { 
      if constexpr(is_same<decltype(x), int>) {
       struct T1 { int getStuff() { return 0; } };
       return T1 {};
      } else { 
       struct T2 { void doStuff() { } };
       return T2 {};
      }
    }

Read the rest of the discussion.

I have seen few videos by Walter Bright, Andrei Alexandrescu on ranges and I have no problem understanding D`s documentation. Maybe you should learn the language before using it.

being a solved problem 40 years ago

Ahh.. welcome to computer "science", the ever repeating cycle of 'inventions'

Not in D, it isn't, for performance reasons. It takes an input range and returns a type that iterates through that range applying the callable (doesn't have to be a function!) to each element as requested.

>It takes an input range

Which should have a type.

>and returns a type that iterates through that range

Which should have a type. The entire point is that this is a solved problem, there is no excuse to simply throw up our hands and say "screw documentation we'll just say this function is a mystery".

Functor f => (a -> b) -> f a -> f b

And please don't miss the point and tell me D doesn't have Functor. The entire point is that D has something, and it doesn't tell us what that something is. It should. Documentation is good.

D has functors, but it doesn't have 'Functor'.

Or rather, D doesn't have concepts (of which 'Functor' is a special case); that is, the notion of a type that is characterized by having the ability to execute operations is not expressible in its typesystem.

Or rather, it is, but only with classes. You want something like "a return type; fulfilling the condition of being able to be used in this way." This is not something you can specify as a function attribute in D. Instead, ranges use a form of duck typing. The next step in the call chain can tell whether the previous step gave it something it can use using template inconditions, ie. `isInputRange!T`. But the previous step can't assert that it is returning a type that fulfills a constraint. In other words, there's type inconditions but not type outconditions.

What you're describing has names - structural types, refined types (a.k.a. contracts a.k.a. pre- and post-conditions)...

It's simply a failure of D the language/compiler (and a huge anti-pattern) to not expose internal types in a way that can be displayed to the programmer.

No such internal type exists. The range interface is purely a library feature. The problem is that D has no way to include a type constraint as a part of the function type, at present. Something like out template contracts would do it probably.

java can't express its types in its own syntax either. nor scala, nor sharp.

ceylon could, but they are barely readable anyway.

> > It takes an input range > Which should have a type.

It does. That'd the `Range` here: https://dlang.org/phobos/std_algorithm_iteration.html#.map.m...

> > and returns a type that iterates through that range > Which should have a type.

It does. But the name of that type depends on the type of the range and on the callable.

> Functor f => (a -> b) -> f a -> f b

This doesn't work because the return type isn't `f b`, it's `g b` where g depends on what f is. It also depends on the callable, because the first parameter isn't necessary a function. The closest is

Callable c, Range r0 => c a b -> r0 a -> r1 b

Where `r1` isn't even a concrete type but a type that depends on both `c` and `r0` and is made up on-the-fly (per instantiation).

> Documentation is good.

I agree. How would you suggest improving the signature of map given that D doesn't have typeclasses? Or with types that depend on other types in the template?

class Range g => FunctorTo f g | f -> g where fmapto :: Callable c => c a b -> f a -> g b

is how you would define that class of types in Haskell. It says "If g is a range, then a pair of types f and g satisfy the FunctorTo interface[1] when knowing f determines g, and there's an implementation of fmapto with this type".

Maybe D needs typeclasses. This thread has certainly put me off of D, because being able to write down types is really quite important to me.

[1] The Haskell class keyword is defines something closer to an interface than an OO class.

> because being able to write down types is really quite important to me.

The issue arises only with generic heavily templated functions. Nothing in D forbids you to write your programs with all types explicitly written down. That's btw how I mostly write my code.

>But the name of that type depends on the type of the range and on the callable.

That should not be a problem. It is a problem in D because of a lacking in D.

>How would you suggest improving the signature of map given that D doesn't have typeclasses?

The language needs fixed so it can express its own types.

> That should not be a problem. It is a problem in D because of a lacking in D.

It is not a problem, the compiler copes with it. The problem comes from the fact that such a type is absolutely not interesting to know how it is written. The unmangled type is unreadable.

Yes, the type is very interesting to know. That's why other languages make it known. Ignoring the entire discussion to reply twice with "nu uh!" is not very productive.

There's usually no reason to know the return type of any range-based function in D. It's not like auto is applied as a return type willy nilly. And anyone who understands D's ranges and how they are used should have no problem seeing a function declaration that returns auto.

Right, the entire world is wrong because you can't admit a fault in a random piece of software you are emotionally invested in. Makes sense.

Not quite. I'm saying that in this case it doesn't matter because of the way the API is used. Is it confusing for people who don't understand D ranges? Yes, it certainly can be. It was for me when ranges first came along. But once you understand how D ranges are intended to be used, then you realize you rarely ever care what the return type is. D is not Rust, or C++, or (insert language here).

When the return type actually matters, auto should be avoided unless there's no way around it. But that's why we have "Returns:" in Ddoc. The function signature itself is not the complete documentation. I mean, you're acting like all D functions are documented to return auto. They aren't. It's used where it needs to be.

> The language needs fixed so it can express its own types.

The language expresses its types just fine (it's in the mangled name in the object file). The issue is that there is no point in the human readable form of these types.

That still means "it returns something".

It gives us much more information than "something". It tells us it is a list of the type of the second argument to the function we passed it. Or in the generic version a "something you can iterate over" of things of the type of the second argument to the function we passed.

Reply on news.ycombinator.com