Hacker News Reader

Comment by haberman | Hacker News Reader

It is strange to pick on C for this, as I cannot think of a single language that works the way the author seems to want. The only exception I can think of is Perl, which has the "wantarray" function that lets a function vary its behavior based on what its return is being assigned to: http://perldoc.perl.org/functions/wantarray.html

With that exception, it's pretty much always assumed that an expression is evaluated independently of what it is being assigned to. I have a feeling that the author's preferred behavior would lead to some surprising results, but I can't think of any good examples off the top of my head.

View on HN

Looks like a use-case for typeclasses, e.g. those in Haskell. A typeclass is like a Java interface, except the method lookup can use the return type as well.

For example, we could make "plus" depend on the return type:

    -- "plus" takes two instances of "Number" and returns an "a"
    class Additive a where
      plus :: (Number b) => b -> b -> a

    -- Take two Numbers and return an Int
    instance Additive Int where
      plus x y = intPlus (toInt x) (toInt y)

    -- Take two Numbers and return a Float
    instance Additive Float where
      plus x y = floatPlus (toFloat x) (toFloat y)

We can even abuse this to do ugly hacks, like making "plus x y" return a list of "[x + y]" when the return type requires a list:

    -- Take two Numbers and return a list containing their sum
    instance (Additive a) => Additive (List a) where
      plus x y = [plus x y]

Alternatively, we could have returned "[plus x 0, plus y 0]" to make things even uglier ;)

The surprise would be if you wanted to, say, add 100 to a uint8 and have it wrap, but were assigning the result to a uint64. Then your arithmetic wouldn't wrap, unless you explicitly told it to, i.e. "x = (y + 100) & 0xff;"

Either way leads to surprises if your intuition tells you the other thing should happen.

Strictly, in C the behaviour is undefined when a signed integer overflows. Although it wouldn't help in the author's case, since he's using unsigned integers, it is valid for a compiler to internally promote the operands of signed arithmetic.

> It is strange to pick on C for this, as I cannot think of a single language that works the way the author seems to want.

Agreed, though recent crop of languages with less implicit conversion will reject the entire thing rather than silently expand the value at the end, e.g. in Rust

    error[E0308]: mismatched types
     --> <anon>:7:19
      |
    7 |     tableOffset = (l1Index * L1_TABLE_GRANULARITY) +
      |                   ^ expected u64, found u32
    
    error: aborting due to previous error

So far I found this mandatory explicit conversion to only get in the way. Caused me a bug even (in Go), because it made it too noisy and very unclear where the value was unnecessarily trimmed.

Yeah it's a mixed blessing, implicit conversions are sources of bugs but the lack of them can be a real pain in the ass when mixing numerics of different bit width. Maybe it's possible to write a rustc plugin to opt-in auto-expansion of numeric types in the style of unsafe blocks? E.g. `extend!(numexpr)` which would go through the numeric expression and automatically (sign-|zero-)extend values to make it typecheck?

It would be nice if languages allowed us to overload function names with the exact same parameters but different return types. The compiler or runtime environment should be able to select the correct implementation automatically based on type inference, or allow the programmer to specify which one should be used with an annotation. This would make some code a little cleaner instead of having to give all of those functions different names.

> It would be nice if languages allowed us to overload function names with the exact same parameters but different return types.

Haskell's typeclasses kind-of do that. `read` has type `Read a => String -> a`, so the result's type `a` (which can be inferred) drives which "Read" instance will be used:

    Prelude> read "1" :: Int
    1
    Prelude> read "1" :: Float
    1.0

> Haskell's typeclasses kind-of do that.

You're over-hedging. As your example shows, Haskell's typeclasses exactly do that.

I'm mostly hedging on the "overloading" part as Haskell doesn't support arbitrary ad-hoc polymorphism in the sense of C++/Java/C# (IIRC the foundational paper on typeclasses is about making ad-hoc polymorphism less ad-hoc). Depending how far into the overloading field nradov is, typeclasses may not match their definition of or requirements for overloading.

It's probably more noticeable in Rust than in Haskell.

Ah, that makes sense. I don't think there's a reasonable way to define "overloading" that excludes typeclasses, but it's true that there are things that can properly be termed "overloading" which typeclasses can't (or shouldn't) do.

> or allow the programmer to specify which one should be used with an annotation.

That's exactly:

> give all of those functions different names.

Similar, but not exactly the same. It would make the syntax and documentation a little cleaner.

Effectively; although "name" usually implies an opaque symbol, e.g. the language would see no difference between, say, "addAsInts" vs. "addAsFloats", compared to "addAsInts" vs. "divide".

Classes, namespaces, modules, etc. allow names to have a more fine-grained structure, e.g. "int.add" and "int.divide" come from the same module, whilst "int.add" and "float.add" are alternative implementations of the same signature.

> whilst "int.add" and "float.add" are alternative implementations of the same signature.

Maybe in a functional programming language like Haskell. But not in C++.

The syntax was just an example ;)

What I described is actually closer to ML.

Has nothing to do with syntax.

Reply on news.ycombinator.com