问题标签 [type-systems]

如果不是，并且引用类型和值类型的集合是互斥的，为什么不编译：

编译器声明：“类型已经定义了一个名为 'Do' 的成员，具有相同的参数类型。”，但这里的 T 和 T 并不相同。一种是受结构约束，另一种是受类约束。对函数的调用应该始终是可解析的。有反例吗？

有人声称 Scala 的类型系统是图灵完备的。我的问题是：

1. 有正式的证明吗？

2. Scala 类型系统中的简单计算会是什么样子？

3. 这对 Scala 有什么好处吗？与没有图灵完整类型系统的语言相比，这是否使 Scala 在某种程度上更“强大”？

我想这通常适用于语言和类型系统。

我已经构建了一个自定义类型系统，用于在应用程序内的 C# 脚本中使用。这些脚本是即时编译的，并允许与应用程序内部数据进行交互。这个类型系统是用抽象的方式设计的，使用的接口如IValue. 的实现IValue可以是RefString, RefInteger, RefDouble（在许多其他中，但这足以证明我的问题）。

现在我们到了我被卡住的地步……这些IValue对象的使用有点不自然。始终使用接口与对象交互被认为是一种好的设计，但不可能为接口定义隐式转换或重载运算符。这产生了不可避免的丑陋显式转换的情况，以便使用正确的运算符。

例子：

对于涉及值类型的表达式中的 C#，提供了隐式转换。设计这种定制系统的好方法是什么？

我重写了类型系统，删除了IValue接口并引入了一个RefValue基类。这样，已经可以消除一部分显式强制转换。我在这个基类中实现了一些运算符重载，但这给默认转换运算符带来了很多麻烦……除此之外，在运算符实现中实现的逻辑涉及到很多关于系统类型的知识。我认为这在某种程度上仍然是一个人必须走的路，但是要遵循什么规则，以一种好的和安全的方式实施呢？

编辑：经过一段时间的努力，我能找到的一些规则是：

• 仅隐式声明来自基本类型（int、double、string、...）的转换运算符
• 显式声明到基本类型的转换（以避免隐式转换为 int！经常发生这种情况，但为什么？）
• 为避免模棱两可的调用，不应在基类和派生类中重写 +、-、/、* 运算符。【那该怎么走呢？我在派生类中进行了操作重载，这需要在使用时进行强制转换，这又是丑陋的......]

在Coders at Work (p355) 一书中，Guy Steele 谈到了 C++：

我认为与 C 向后兼容的决定是一个致命的缺陷。这只是一系列无法​​克服的困难。C 基本上有一个损坏的类型系统。它足以帮助您避免一些困难，但它不是密封的，您不能指望它

他将类型系统描述为“腐败”是什么意思？

你能用 C 语言的一个简单例子来演示吗？

编辑：

1. 这句话听起来很有争议，但我不想成为。我只是想明白他的意思。

2. 请用C而不是C++给出例子。我也对“基本”部分感兴趣:)

我正在制作一个几何库，但我很困惑，计算一个段与另一个段的交集的函数的返回类型应该是什么。返回的值有时是一个点，有时是一个段（重叠情况），有时是一个空集。根据我的想法，可以有 3 种方法来解决这个问题，如下所示： 1. 返回一个联合（段，空，点） 2. 当交点是一个点并且两个点都为NAN 当交集为空集 3. 返回一个向量（空集为 0 个元素，pnt 为 1 个元素，段为 2 个元素）

请让我知道是否有任何替代方案以及每种设计的优缺点。此外，哪个设计应该是一个好的设计以及为什么。我有兴趣制作一个健壮的架构，它允许单管道，因此几乎不需要重写代码以及可扩展（在添加功能和处理所有边缘情况方面）

以下是我的参考代码（其返回类型为矢量）

怎么来的，下面的类型检查

但是当将 setFunFoo 的类型签名更改为

它不是？有没有办法在没有类型同义词 FunFoo 的情况下表达上述代码？

我已经阅读了C# 和 Java 的比较，列表中的第一件事是“单根（统一）类型系统”。

你能描述一下单根（统一）类型系统的含义吗？

I cannot really get it. Why do we need it at all? I mean if I use the same type parameter, I think that means they should be the same type.

I heard it can help the compiler to avoid the infinite loop. Can someone tell me some more details about that?

In the end, are there any 'patterns and practices' we should follow on the usage of functional dependency in Real World Haskell?

[Follow-up Question]

In the code above, I used the same type variable 'a' for both container and element, I think the compiler can thus infer that these two types are the same type.

But when I tried this code in GHCi, I got the following feedback:

When one of them has been specified to be type 'Char', why the other one is still unresolved type 'element'?

我定义了以下结构：

后来，我将它分配给另一个对象的 Tag 属性：

但是当我尝试像这样检索 Tag 属性时，

Visual Studio 给出以下编译时错误：

运算符 as 必须在引用类型或可为空的类型中使用

那是什么意思？我该如何解决？

我想知道为什么在编译时检查 C# 中的某些强制转换，而在其他情况下，责任转嫁给 CLR。像上面一样，两者都是不正确的，但以不同的方式处理。

在阅读“深入 C#”时，我发现有关此主题的信息，其中 autor 说：
“如果编译器发现该强制转换实际上不可能工作，它将触发编译错误 - 如果理论上允许但实际上在执行时不正确，CLR 将抛出异常。”

“理论上”是指通过继承层次结构连接（对象之间的另一种亲和力？）还是编译器的内部业务？