Questions tagged «type-inference»

我对haskell编译器有时会推断出比我期望的少多态的类型感到困惑，例如，在使用无点定义时。 似乎问题出在“单态限制”，在较早版本的编译器上默认启用。 考虑以下haskell程序： {-# LANGUAGE MonomorphismRestriction #-} import Data.List(sortBy) plus = (+) plus' x = (+ x) sort = sortBy compare main = do print $ plus' 1.0 2.0 print $ plus 1.0 2.0 print $ sort [3, 1, 2] 如果我使用它进行编译，则ghc不会得到错误，并且可执行文件的输出为： 3.0 3.0 [1,2,3] 如果我将main主体更改为： main = do print $ …

76 haskell  types  polymorphism  type-inference  monomorphism-restriction 

许多博客和手册本身都说Julia是动态键入的。但是从我对手册的阅读中，听起来更像是使用类型推断（例如F＃） 静态键入的。 朱莉娅是否使用类型推断静态键入？ 它是动态输入的吗？ 我假设它是动态键入的，手册似乎不太可能是错误的。 Julia完全涉及类型推断吗？

74 types  type-inference  julia 

我在泛型方法中有很多有趣的乐趣（希望有乐趣）。在大多数情况下，C＃类型推断足够聪明，可以找出必须在我的泛型方法上使用哪些泛型参数，但是现在我有了一个C＃编译器不会成功的设计，而我相信它可以成功找到正确的类型。 谁能告诉我在这种情况下编译器是否有点笨，还是有一个很明确的原因为什么它不能推断我的通用参数？ 这是代码： 类和接口定义： interface IQuery<TResult> { } interface IQueryProcessor { TResult Process<TQuery, TResult>(TQuery query) where TQuery : IQuery<TResult>; } class SomeQuery : IQuery<string> { } 一些无法编译的代码： class Test { void Test(IQueryProcessor p) { var query = new SomeQuery(); // Does not compile :-( p.Process(query); // Must explicitly write all …

71 c#  .net  c#-4.0  type-inference 

F＃编译器似乎以（相当）严格的从上到下，从左到右的方式执行类型推断。这意味着您必须做一些事情，例如将所有定义放到使用之前，文件编译的顺序很重要，并且您往往需要重新整理内容（通过|>或通过您拥有的东西），以避免使用显式的类型注释。 使它更加灵活有多难，并且计划在F＃的未来版本中使用它吗？显然，这是可以做到的，因为Haskell（例如）在推理能力相当强的情况下没有这种限制。导致此问题的F＃的设计或意识形态与生俱来有什么不同？

67 f#  language-design  type-inference 

使用的方法引用具有返回类型Integer。但是String在下面的示例中，允许不兼容。 如何解决方法with声明以确保方法引用类型安全而无需手动强制转换？ import java.util.function.Function; public class MinimalExample { static public class Builder<T> { final Class<T> clazz; Builder(Class<T> clazz) { this.clazz = clazz; } static <T> Builder<T> of(Class<T> clazz) { return new Builder<T>(clazz); } <R> Builder<T> with(Function<T, R> getter, R returnValue) { return null; //TODO } } static public interface MyInterface …

38 java  generics  lambda  type-inference  method-reference 

大家都知道龙延伸Number。那么为什么不编译呢？ 以及如何定义方法with，使程序无需任何手工转换就可以编译？ import java.util.function.Function; public class Builder<T> { static public interface MyInterface { Number getNumber(); Long getLong(); } public <F extends Function<T, R>, R> Builder<T> with(F getter, R returnValue) { return null;//TODO } public static void main(String[] args) { // works: new Builder<MyInterface>().with(MyInterface::getLong, 4L); // works: new Builder<MyInterface>().with(MyInterface::getNumber, (Number) 4L); …

19 java  type-inference 

的实现std::mem::drop记录如下： pub fn drop<T>(_x: T) { } 因此，我希望该封盖|_| ()（俗称马桶盖）drop在两个方向上都可以按1：1的比例替换。但是，下面的代码显示drop与该函数的参数上绑定的较高特级特征不兼容，而马桶盖则兼容。 fn foo<F, T>(f: F, x: T) where for<'a> F: FnOnce(&'a T), { dbg!(f(&x)); } fn main() { foo(|_| (), "toilet closure"); // this compiles foo(drop, "drop"); // this does not! } 编译器的错误信息： error[E0631]: type mismatch in function arguments --> src/main.rs:10:5 | …

13 rust  closures  traits  type-inference  higher-kinded-types 

为什么是 public <R, F extends Function<T, R>> Builder<T> withX(F getter, R returnValue) {...} 然后更严格 public <R> Builder<T> with(Function<T, R> getter, R returnValue) {...} 这是为什么在编译时不检查lambda返回类型的后续操作。我发现使用withX()类似的方法 .withX(MyInterface::getLength, "I am not a Long") 产生所需的编译时错误： 类型BuilderExample.MyInterface中的getLength（）类型很长，这与描述符的返回类型不兼容：字符串 而使用该方法with()则没有。 完整的例子： import java.util.function.Function; public class SO58376589 { public static class Builder<T> { public <R, F extends Function<T, …

12 java  generics  lambda  type-inference 

当类型参数来自封闭方法而不是封闭类时，为什么模式匹配的工作方式有所不同？例如， trait Base[T] case class Derived(v: Int) extends Base[Int] class Test[A] { def method(arg: Base[A]) = { arg match { case Derived(_) => 42 } } } 给出错误 constructor cannot be instantiated to expected type; found : A$A87.this.Derived required: A$A87.this.Base[A] case Derived(_) => 42 ^ 虽然它成功地编译A为方法类型参数 class Test { def …

9 scala  pattern-matching  type-inference  type-parameter