首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
MCP广场
社区首页 >问答首页 >哪些语言习惯用法/范例/特性使得添加对“类型提供程序”的支持变得困难?

哪些语言习惯用法/范例/特性使得添加对“类型提供程序”的支持变得困难?
EN

Stack Overflow用户
提问于 2011-09-15 17:15:45
回答 3查看 490关注 0票数 6

F# 3.0增加了type providers

我想知道是否有可能将此语言功能添加到运行在CLR上的其他语言中,如C#,或者此功能是否只在功能更强大/面向对象更少的编程风格中才能很好地工作?

EN

回答 3

Stack Overflow用户

回答已采纳

发布于 2011-09-15 23:25:38

正如Brian和Tomas指出的那样,这个特性没有什么特别的“功能性”。这只是一种向编译器提供元数据的特别巧妙的方式。

C#设计团队已经考虑这样的想法很长一段时间了。在我加入C#团队的几年前,有一个提议是关于一种将被称为“类型蓝图”(或类似的东西)的特性,通过该特性,C#编译器可以使用XML文档、XML schema和提供类型元数据的自定义代码的组合。我不记得细节了,显然,它从来没有实现过。(尽管它确实影响了Visual Studio Tools for Office document format的设计和实现,我当时正在从事这项工作。)

无论如何,我们目前还没有计划在C#中添加这样的功能,但我们正怀着极大的兴趣关注它是否能很好地解决F#的客户问题。

(和往常一样,Eric对未宣布的和完全假设的产品未来可能的功能的思考仅用于娱乐目的。)

票数 7
EN

Stack Overflow用户

发布于 2011-09-15 19:47:21

正如Tomas所说,理论上将这种特性添加到任何静态类型的语言中是很简单的(尽管仍然有很多繁琐的工作)。

我不是元编程专家,但@SK-logic问为什么不使用通用的编译时元编程系统,我将尝试回答。我不认为您可以使用元编程轻松实现使用F#类型提供程序所能做的事情,因为F#类型提供程序在设计时可能是惰性的和动态交互的。让我们举一个例子,唐在他之前的一个视频中演示了:一个Freebase类型的提供者。Freebase有点像一个系统化的,可编程的维基百科,它有关于所有东西的数据。因此,您可以像下面这样编写代码:

代码语言:javascript
运行
复制
for e in Freebase.Science.``Chemical Elements`` do
    printfn "%d: %s - %s" e.``Atomic number`` e.Name e.Discoverer.Name

或者诸如此类的东西(我手头没有确切的代码),但同样容易编写代码来获取有关棒球统计数据的信息,或者著名演员在戒毒所的时间,或者可以通过Freebase获得的无数其他类型的信息。

从实现的角度来看,为所有Freebase生成模式并预先将其带入.NET是不可行的;您不能只在一开始就执行一个编译时步骤来设置所有这一切。您可以对小型数据源执行此操作,事实上,许多其他类型提供程序都使用此策略,例如,SQL类型提供程序指向数据库,并为该数据库中的所有类型生成.NET类型。但是这种策略对像Freebase这样的大型云数据存储不起作用,因为有太多相互关联的类型(如果您尝试为所有Freebase生成.NET元数据,您会发现有如此之多的类型(其中一个是带有AtomicNumberDiscovererChemicalElement,以及Name和许多其他字段,但实际上有数百万这样的类型),以至于您需要比32位.NET进程可用的更多的内存来表示整个类型架构。

因此,类型提供程序策略是一种允许类型提供程序按需提供信息的F#体系结构,在设计时在集成开发环境中运行。例如,在您键入Freebase.Science.之前,类型提供程序不需要知道科学类别下的实体,但是一旦您在Science之后按下.,类型提供程序就可以查询API,以了解整个模式的一个更高级别,以了解在科学下存在哪些类别,其中一个类别是ChemicalElements。然后,当您尝试“点进”其中一个元素时,它会发现元素有原子序号之类的。因此,类型提供程序懒惰地从整个模式中获取足够的内容,以处理用户恰好在那个时刻输入编辑器的确切代码。因此,用户仍然可以自由地探索信息宇宙的任何部分,但任何一个源代码文件或交互式会话都只会探索可用内容的一小部分。当需要编译/codegen时,编译器只需要生成足够的代码来容纳用户在其代码中实际使用的位,而不是潜在的巨大运行时位来提供与整个数据存储对话的可能性。

(也许你现在可以用现在的一些元编程工具做到这一点,我不知道,但是我很久以前在学校学到的那些工具不能很容易地处理这个问题。)

票数 8
EN

Stack Overflow用户

发布于 2011-09-15 18:23:39

我没有看到任何技术原因,为什么不能将类型提供程序之类的东西添加到C#或类似的语言中。使添加类型提供程序变得困难的唯一语言系列(与F#中的方式类似)是动态类型语言。

F#类型提供程序依赖于这样一个事实,即提供程序生成的类型信息可以很好地在程序中传播,并且编辑器可以使用它们来显示有用的IntelliSense。在动态类型语言中,这将需要更复杂的集成开发环境支持(动态语言的“类型提供程序”仅限于集成开发环境或IntelliSense)。

为什么它们被直接实现为F#的一个特性?我认为元编程系统必须非常复杂(请注意,类型实际上并不是生成的)才能支持它。使用它可以完成的其他事情对F#语言的贡献不会太大(它们只会使它变得太复杂,这是一件坏事)。但是,如果您具有某种编译器可扩展性,您可能会得到类似的结果。

事实上,我认为这就是C#团队未来将如何添加类似类型提供程序的东西(他们已经讨论了一段时间的编译器可扩展性)。

票数 5
EN
页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接:

https://stackoverflow.com/questions/7428531

复制
相关文章

相似问题

领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档