Hacker News Reader

Comment by ekidd | Hacker News Reader

Yeah, this is a really great Haskell feature, and it often feels like magic the first time you see it. It's key to a whole lot of useful Haskell idioms.

Well-known languages which do this include Haskell and Rust (where it's also useful). In Rust, you can write things like:

    // Generate an appropriate default value for a type.
    // Here, this will create an empty vector of String.
    let my_vec: Vec<String> = Default::default();
    
    // Parse JSON into the specified type.
    let numbers: Vec<u32> = serde_json::from_str("[1, 2, 3]")?;

I think there may be ways to do something similar with C++ template metaprogramming and partial specialization, and I wouldn't be surprised if some of the ML family supported something similar using "modules". (But I don't really understand ML modules, so don't quote me on that.)

It's a great feature, and I would love for more strongly-typed languages to support it.

View on HN

Yes, it feels great to just drop `read` into a context with enough type information to infer the return type.

On the other hand, when the type context is not sufficient, it gets a bit bulky:

   -- with sufficient type context:
   xs <- map read <$> lines <$> getContents

   -- an ugly inline type signature:
   xs <- map (read :: String -> Int) <$> lines <$> getContents

For many such calls it's good to monomorphize:

   readInt :: String -> Int
   readInt = read

but it still does not feel elegant (what about other return types?).

Edit: obviously, this must have been `xs <-`, not `let xs =`.

Couldn't you just type `xs` as `[Int]` and let the compiler work itself backwards from there?

I don't know how can I actually do this inside a do-block:

    xs :: [Int] <- ...

does not work without `ScopedTypeVariables` (and I don't like proliferation of redundant language extensions).

In Rust, sure, it's not a problem and plays well with the language.

My point is, it is easy to abuse this feature (this example is from Haskell Prelude!), even though it is indispensable in some situations (like `mempty :: a`).

You can either type the return value at the end of your line:

    xs <- map read <$> lines <$> getContents :: IO [Int]

Or you can force the xs type on some other line:

    let _ = xs :: Int

There is a recent idiom for that last format that lets you write on the same line as the expression. I think it's something like:

    (xs @ [Int]) <- map read <$> lines <$> getContents

But I haven't used it yet and I am not sure exactly what version of GHC allows it.

Today I learned that `:: IO [Int]` at the end of an expression is applied to the whole expression. Thanks!

Almost all Haskell code written these days uses at least a handful, if not a barrel-full, of extensions, and ScopedTypeVariables is one of the most common ones. Of course, you’re completely free to do whatever you’d like with your own code, but you’ll probably find it hard to avoid extensions — at the least many of them will be used by some libraries you’re depending on.

> does not work without `ScopedTypeVariables` (and I don't like proliferation of redundant language extensions).

It does something useful for you! How can it be redundant?

You don't like the part where compiler authors are free to make efforts to improve the language that are clearly delineated as not part of the standard and easy to not enable if they prove to not be a good idea in practice?

What are the alternatives? Completely discarding the language standard? Never making attempts to improve the language? Requiring all experiments to go through a standardization committee before real-world testing?

None of those strike me as obviously better.

I am definitely not against languages extensions in general. I think that it's one of the unique features of Haskell that keep it stable and flexible at the same time.

If I already have `ScopedTypeVariables` in scope for other valid reasons, I am happy to use it. It's just that I'd rather not enable it for tiny cosmetic improvement like this.

If it makes you feel any better, I suspect that ScopedTypeVariables is basically how it should have worked in the first place. (The default behavior is pretty weird/surprising.)

Is magic worth anything if it doesn’t work on 100% of its surface?

Isn’t “use magic, except in cases where the magical internals don’t apply—then be explicit” a strictly worse API than “just be explicit”?

Return type polymorphism has usecases where it is irreplaceable (see other comment threads).

I am just pointing out an example of bad use, which is not a problem of the language, just of this specific API.

As for APIs in general, sometimes they do need some leeway for future extension.

In general you can't do it in C++. There is no way to propagate the result type to the function call itself.

The workaround it to return a proxy object with a template conversion operator, which is very effective but it is a leaking abstraction.

edit: as long as you are willing to manually specify the result type you can of course have an additional template argument which is not deduced from any function arguments.

This is part of the reason why I still feel constrained when using systems where the type system is bolted on after the fact, like Typescript, Flow, or Dialyzer. You can gain so much leverage from the type system being able to generate code like this for you.

ML can do this, but you have to mention the module explicitly. OCaml's upcoming modular implicits will allow this with less boilerplate though.

If I've understood this correctly, you can more or less do this in C++ by using voldemort types.

Here's a nonsensical but demonstrative example program:

  #include <string>
  #include <iostream>
  
  auto polyret()
  {
      struct proof_of_concept
      {
          operator int() { return 4; }
          operator double() { return 1.5; }
          operator std::string() { return "I'm a string!"; }
      };
      return proof_of_concept();
  }
  
  int main()
  {
      int a = polyret();
      double b = polyret();
      std::string c = polyret();
      std::cout << "int: " << a << std::endl; //prints 4
      std::cout << "double: " << b << std::endl; //prints 1.5
      std::cout << "string: " << c << std::endl; //prints "I'm a string!"
  }

Oddly, at the totally other end of the type-system spectrum, the "wantarray" feature of Perl allows you to implement this behavior yourself for a subset (two, in this case) of Perl's main data types* .

http://perldoc.perl.org/functions/wantarray.html

You have to wire it up yourself, and it happens at runtime (because most everything interesting in Perl does) but your function can alter its return type from a scalar to a vector (list, in Perl parlance. Pearlance? Nevermind) based on the way in which it is invoked.

I've seen this used for great evil and great good, but regardless: it's an interesting case in point that such features can be present (albeit in really different forms) and useful even in languages that bear very little resemblance to Haskell/Rust/etc.

*contexts, in this case, but it allows for equivalent behavior to return-type polymorphism in a very limited way.

Edit: formatting.

Reply on news.ycombinator.com