得到类型推断,想要添加类继承

发布于 2024-08-16 12:16:40 字数 1014 浏览 6 评论 0原文

如果我设计一种具有类型推断、没有显式类型且没有类继承支持的新语言,然后想要添加继承,那么在添加该功能时,为解决类型歧义而需要向编译器提供的最低额外提示是什么?

需要类名吗?

编辑

类型污染是通过整个程序(包括函数之间)的分配来跟踪的。

好的,在起始语言中,您可以从以下内容中获得类似 MyTypeName1 的类名称:

myVariable1 = New(MyTypeName1)
myVariable2 = New(MyTypeName2)

并且类型 MyTypeName1MyTypeName2 是为 myVariable1< 推断出来的分别为 /code> 和 myVariable2。但是,如果我们想要增强语言支持:

MyVariable3 = myVariable1
MyVariable3 = myVariable2

可以通过代码进行跟踪(myVariable3 现在可以包含两种类型,这两种类型可能位于层次结构中)。

编辑

MyTypeName1 和 MyTypeName2 的成员是从以下语句推断出来的:

myVariable1.name="Fred"
myVariable2.name="JX3009"

如果 MyTypeName1MyTypeName2 中的 name 成员不在 a 中怎么办?公共基类?如果我们想要在 MyTypeName1MyTypeName2 中使用不同的 name 属性,而在基类中没有一个属性怎么办?有没有一种优雅的方式告诉编译器要做什么/如何处理? (类型推断的想法是减少输入而不是增加输入......?)

或者我们是否需要显式指定层次结构?

If I design a new language with type inference, no explicit types and no class inheritance support and then want to add inheritance, what are the minimum extra hints to the compiler needed to resolve type ambiguity when adding the feature?

Are class names needed?

EDIT

The type-tainting is traced through assignments throughout the program including between functions.

OK in the starting language, you have class names like MyTypeName1 from stuff like:

myVariable1 = New(MyTypeName1)
myVariable2 = New(MyTypeName2)

And types MyTypeName1 and MyTypeName2 are inferred for myVariable1 and myVariable2 respectively. But then if we want to enhance the language to support:

MyVariable3 = myVariable1
MyVariable3 = myVariable2

which can be traced through the code (myVariable3 now can contain two types which presumably are in a hierarchy).

EDIT

The members of MyTypeName1 and MyTypeName2 are inferred from statements like:

myVariable1.name="Fred"
myVariable2.name="JX3009"

What if the name member in MyTypeName1 and in MyTypeName2 are not to be in a common base class? What if we want a different name property in MyTypeName1 and MyTypeName2 and none in a base class? Is there an elegant way to tell the compiler what to do / how to handle? (The idea with type inference is to reduce typing not increase it...?)

Or do we need to specify the hierarchy explicitly?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

叹倦 2024-08-23 12:16:40

这个字段充满了不确定性结果,但我已经把它们全部忘记了。如果您愿意将继承与子类型混为一谈,那么就没有问题。如果你想要一些更有野心的东西(听起来好像你确实想要),我会看看

  • Benjamin Pierce的教科书类型和编程语言,它将涵盖宽度和深度子类型的基本结果以及它们如何与类型推断很好地配合。 (我会看看自己,但我的副本正在工作。)

  • François Pottier 的博士论文。

另一个值得关注的名字是 Joe Wells,他负责类型系统和编程语言中的许多不确定性结果。

编译器解决类型歧义所需的最少额外提示是什么?

如果这个问题有一个独特的答案,我会感到非常惊讶。我认为这更有可能是语言设计问题之一,其中有一堆解决方案在极简性和注释方面是严格无法比拟的。

This field is loaded with undecidability results, but I've forgotten them all. If you're willing to conflate inheritance with subtyping, then you have no problems. If you want something more ambitious (and it sounds as if you do), I'd have a look at

  • Benjamin Pierce's textbook Types and Programming Languages, which will cover the basic results for width and depth subtyping and how they do or do not play nicely with type inference. (I'd look myself but my copy is at work.)

  • François Pottier's PhD dissertation.

Another name to check out is Joe Wells, who's been responsible for a lot of undecidability results in type systems and programming languages.

What are the minimum extra hints to the compiler needed to resolve type ambiguity?

If there is a unique answer to this question, I will be very surprised. I think it far more likely that this is one of those language-design problems where there are a bunch of solutions which are strictly incomparable as far as minimality and annotations go.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文