4 ms·

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 P

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

nradov 10y ago
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.
- masklinn 10y ago
  > 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
  - dllthomas 10y ago
    > Haskell's typeclasses kind-of do that. You're over-hedging. As your example shows, Haskell's typeclasses exactly do that.
    - masklinn 10y ago
      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.
      - dllthomas 10y ago
        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.
- fredmorcos 10y ago
  > or allow the programmer to specify which one should be used with an annotation. That's exactly: > give all of those functions different names.
  - nradov 10y ago
    Similar, but not exactly the same. It would make the syntax and documentation a little cleaner.
  - chriswarbo 10y ago
    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.
    - fredmorcos 10y ago
      > 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++.
      - chriswarbo 10y ago
        The syntax was just an example ;) What I described is actually closer to ML.
        fredmorcos 10y ago
        Has nothing to do with syntax.
masklinn 10y ago
> 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
- zzzcpan 10y ago
  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.
  - masklinn 10y ago
    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?
chriswarbo 10y ago
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 ;)
parenthephobia 10y ago
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.

nradov 10y ago

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.

masklinn 10y ago
> 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
- dllthomas 10y ago
  > Haskell's typeclasses kind-of do that. You're over-hedging. As your example shows, Haskell's typeclasses exactly do that.
  - masklinn 10y ago
    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.
    - dllthomas 10y ago
      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.
fredmorcos 10y ago
> or allow the programmer to specify which one should be used with an annotation. That's exactly: > give all of those functions different names.
- nradov 10y ago
  Similar, but not exactly the same. It would make the syntax and documentation a little cleaner.
- chriswarbo 10y ago
  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.
  - fredmorcos 10y ago
    > 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++.
    - chriswarbo 10y ago
      The syntax was just an example ;) What I described is actually closer to ML.
      - fredmorcos 10y ago
        Has nothing to do with syntax.

masklinn 10y ago

> 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

zzzcpan 10y ago
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.
- masklinn 10y ago
  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?

chriswarbo 10y ago

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 ;)

parenthephobia 10y ago

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.