Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon. Entire thread

Type inference woes

Name: Anonymous 2019-01-25 15:56

CONSIDER this Rust code that a reasonable human being might try to write:

fn add<T>(a: T, b: T) -> T {
return a + b;
}
If you try to compile that, you’ll get an error like this:

:1:25: 1:30 error: binary operation `+` cannot be applied to type `T`
What you actually have to write is something like this:

use std::ops::Add;
fn add<T: Add>(a: T, b: T) -> T::Output {
return a + b;
}
Now it typechecks correctly.

This seems a little ridiculous. The compiler already knew that T had to be a type that supports addition — it just told me that. So why am I spelling it out?

Name: Anonymous 2019-01-25 16:09

>>1
This has nothing to do with type inference - it only has to do with you giving it an incorrect type. \((t : *) \to Add\ t \to t \to t \to t\) is not the same as \((t : *) \to t \to t \to t\).
Type inference is about the types being inferred without having to write any types at all - for example if you could write fn add(a, b) { return a + b; }.
In any case, you should not be using rust. Consider Coq instead.

Name: Anonymous 2019-01-25 17:20

This has nothing to do with type inference
use std::ops::Add;
Doubt.jpg

Name: Anonymous 2019-01-25 18:17

>>3
The use thing has only to do with the namespace/module system. Do you even know what type inference is? Edited on 25/01/2019 18:18.

Name: Anonymous 2019-01-25 21:32

>>2
Serious question, are you

Name: Anonymous 2019-01-26 1:42

>>5
Am I what? A reptilian? I wish I were but sadly I am not.
A Jew? Again, I wish I were one. After all they are some of the smartest people on earth and god's chosen.

Name: Anonymous 2019-01-26 7:18

>>4
Type inference doesn't require importing library modules. This is not type inference, this is type specialization aka
Sepples templates.

Name: Anonymous 2019-01-26 7:19

Tbh std::ops::Add; even looks like Sepples operator overloading...

Name: Anonymous 2019-01-26 7:28

Look at all this "type inference" rust shills advertise!
https://github.com/rust-lang/rust/blob/master/src/libcore/ops/arith.rs
#[lang = "add"]
#[stable(feature = "rust1", since = "1.0.0")]
#[rustc_on_unimplemented(
on(
all(_Self="{integer}", RHS="{float}"),
message="cannot add a float to an integer",
),
on(
all(_Self="{float}", RHS="{integer}"),
message="cannot add an integer to a float",
),
message="cannot add `{RHS}` to `{Self}`",
label="no implementation for `{Self} + {RHS}`",
)]
#[doc(alias = "+")]
pub trait Add<RHS=Self> {
/// The resulting type after applying the `+` operator.
#[stable(feature = "rust1", since = "1.0.0")]
type Output;

/// Performs the `+` operation.
#[must_use]
#[stable(feature = "rust1", since = "1.0.0")]
fn add(self, rhs: RHS) -> Self::Output;
}

macro_rules! add_impl {
($($t:ty)*) => ($(
#[stable(feature = "rust1", since = "1.0.0")]
impl Add for $t {
type Output = $t;

#[inline]
#[rustc_inherit_overflow_checks]
fn add(self, other: $t) -> $t { self + other }
}

forward_ref_binop! { impl Add, add for $t, $t }
)*)
}

add_impl! { usize u8 u16 u32 u64 u128 isize i8 i16 i32 i64 i128 f32 f64 }

Name: Anonymous 2019-01-26 7:30

add_impl! { usize u8 u16 u32 u64 u128 isize i8 i16 i32 i64 i128 f32 f64 }
The power of Cultural Marxist programming

Name: Anonymous 2019-01-26 7:34

This is even weaker than C _Generic macros
(Because you can make _Generic accept compile-time arguments and it has a default: type) Edited on 26/01/2019 07:48.

Name: Anonymous 2019-01-26 11:33

>>10
This thind can't even handle something like 'unsigned long int' since it would interpret it as 3 types 'unsigned','long' and 'int', because its implemented without commas.

Name: Anonymous 2019-01-26 12:31

>>7
Importing library modules has nothing to do with type inference. This whole thread is about a mental midget complaining why the compiler throws an error on his incorrect type definition. Literally every single language with type inference will throw the same error.

Mental midgetry:
import Prelude ((+))

test :: a -> a -> a
test x y = x + y

• No instance for (GHC.Num.Num a) arising from a use of ‘+’
Possible fix:
add (GHC.Num.Num a) to the context of
the type signature for:
test :: forall a. a -> a -> a
• In the expression: x + y
In an equation for ‘test’: test x y = x + y

Type inference is about the typed being inferred, test x y = x + y without any type declaration works just fine for example.

Here is the fix for the first one:
import Prelude ((+), Num)

test :: Num a => a -> a -> a
test x y = x + y
Surprisingly similar, huh?

In any case, rust advertises type inference ONLY for the code inside a function - not for its arguments and return types.

>>11
What? I am pretty sure that traits can do the same in rust.

>>12
Why would you put spaces between your type variables?

Name: Anonymous 2019-01-26 13:33

This whole thread is comedy gold
enum specialint : int;
specialint operator+(specialint a,specialint b){return (specialint)(a&b);}
float operator*(specialint a,float c){return (float)(a)/c;}
auto add(auto a,auto b){return a+b;}
#include <iostream>
int main(){
specialint z=(specialint)0xff;
specialint q=(specialint)1;
std::cout << "Add1:" << z+q <<" Mul:"<< z*2.0f<< " Add2:"<< add(z,q) << " Add3:"<<add(z,2.0);}

Name: Anonymous 2019-01-26 18:11

>>24
What is this supposed to be?

Name: Anonymous 2019-01-26 18:55

>>15
That Sepples is actually better in this case. Do you see any 'using std::Ops::Peano_Arithmetic' or import StoneCountingPrimitives ?

Name: Anonymous 2019-01-26 19:45

>>16
No but I see int, float, specialint, specialint, specialint, float, float, specialint, specialint, specialing, specialing, #include <iostream>, and std::

Name: Anonymous 2019-01-27 7:29

#include <iostream>/std::cout is for printing only, it has nothing to with types. You have no argument here.

Name: Anonymous 2019-01-27 12:15

>>17
The whole argument is that
A.Sepples doesn't need anything besides
auto add(auto a,auto b){return a+b;}
B.It correctly handles operator overloads of user-defined types such as specialint.

Rust and Haskell require importing a specialized method to deal with this.

Name: Anonymous 2019-01-27 12:41

Haskell require importing a specialized method to deal with this.
No?

add x y = x + y

data SpecialInt = MkSpecialInt Int

instance Num SpecialInt where
MkSpecialInt a + MkSpecialInt b = MkSpecialInt (a + b)

Name: Anonymous 2019-01-28 7:09

>>19
your're are right about Rust being shit but don't bring haskal into that. that's how short the definition of your're are generic addition function can be:
x=(+)

the compiler will infer the type for you:
> :t x

x :: Num a => a -> a -> a

Name: Anonymous 2019-01-28 7:15

>:t >>22

>>22 :: Dubs p => p

Name: Anonymous 2019-01-28 7:36

>>22

Dubs are a class of numbers that end in repeating digits. How can dubs be implemented in dead dog?

Name: Anonymous 2019-01-28 7:39

>>23
I don't think you can have a real dubs typeclass, although I'm a novice haskaler. maybe people who make recursion scheme magic libraries could implement dubs as some kind of a recursive church numeral represntation, dunno

Name: Anonymous 2019-01-28 7:51

>>20,21
Whats the deal with 'import Prelude' then
i.e. why >>13 needs to import the (+)
import Prelude ((+)) Edited on 28/01/2019 07:52.

Name: Anonymous 2019-01-28 8:36

>>25
this is not really needed, >>21 works without it. everything from Prelude is automatically imported. import Prleude((+)) is an optimization so that instead of importing the whole Prelude, it imports only the add function.

Name: Anonymous 2019-01-28 9:34

>>26
Shouldn't the arithmethic operators be part of a language, like C++?
Why are they inside a library?
Haskell is not a minimalist language, so this doesn't make sense.

Name: Anonymous 2019-01-28 9:38

Haskell:
import StoneCountingPrimitives
import Booleans
import OptionTypes
import Arithmethic
import ComparisonOperators
import Functions
https://hackage.haskell.org/package/base-4.12.0.0/docs/Prelude.html

Name: Anonymous 2019-01-28 9:42

>>27
math operators are functions, not magic language constructs. Prelude is a minimal library which includes them, and you get it imported implicitly. what's the problem here?

Name: Anonymous 2019-01-28 9:51

>>27
Non-primitives should not be outside a library.

Name: Anonymous 2019-01-28 9:54

>>29
Implicitly depending on library to provide such primitive constructs is wrong in principle. It would if Sepples decided
you need (and include by default unless you #define NO_DEFAULT_HEADER_INCLUDE )
#include <ComparisonLogic> to use >,==,<,!=
#include <Functions> to create functions()
#include <DataTypes> to use ints/floats
#include <BinaryLogic> to use &,|,^
#include <BooleanLogic> to use &&,||
#include <Arithmethic> to use +,-,*,/
Do you see what i mean?

Name: Anonymous 2019-01-28 9:56

>>31
I don't think it would be bad. I think a small base language and big libraries is a good approach.

Name: Anonymous 2019-01-28 10:02

>>32
This would makes sense if Haskell was a minimalistic concept language like brainfuck, but Haskell runtime is huge.

Name: Anonymous 2019-01-28 10:11

It takes a special kind of autism to declare addition impure and unworthy of being a native construct. Reminds me of original Lisp numerals being lists(as in lists of size N being used as numeral N).

Name: Anonymous 2019-01-28 10:12

>>33
conceptually, the base language isn't that complex. the standard libraries are (because they build a more-or-less usable language from a simple, abstract base), and so is the compiler (because it does a lot of crazy optimizations), but the language syntax is quite small. the syntax is still not context-free, but it's still nothing compared to sepples https://www.haskell.org/onlinereport/haskell2010/haskellch10.html

Name: Anonymous 2019-01-28 10:15

>>34
which Lisps did this? also, such a construction has its uses, but definitely not in general case - it allows using recursion schemes on numbers though, which is cool

Name: Anonymous 2019-01-28 10:21

>>36
http://www-formal.stanford.edu/jmc/history/lisp/node4.html

Name: Anonymous 2019-01-28 10:28

LISP 1.5 Update :
Dear Lisp users, we're introducing a
revolutionary concept, Numbers.
Numbers are faster than Church numerals(currently represented as lists of atoms) by several orders of magnitude.
They also require much less memory to store, so you can run bigger programs.
You can now enjoy new vast options of using complex math functions such as sqrt, fact and fibs.
--John McCarthy

Name: Anonymous 2019-01-28 11:02

>>38
Not upgrading, since i believe these Numbers belong in libraries. They're too hardware-specific to be a native language feature.
I'm also skeptical about the advertised speed advantages of these newfangled "Numbers", since they're probably tested on non-LISP optimizaed machines.

Name: Anonymous 2019-01-28 11:35

>>38
Who needs these FORTRAN anachronisms? We can calculate everything(Church-Turing thesis) in Church numerals!
https://en.wikipedia.org/wiki/Church_encoding#Calculation_with_Church_numerals
If we wanted FORTRAN, then we would use FORTRAN. Please remove this idiotic "speed hack" from LISP.
Newer Posts
Don't change these.
Name: Email:
Entire Thread Thread List
All trademarks and copyrights on this site are owned by their respective parties. All comments and posts are the responsibility of their own posters.
- Tinychan + 2ch Mode + RSS -