c# - 哪种语言习语/范式/特性使得添加对 "type providers"的支持变得困难？

Question

F# 3.0 添加了 type providers .

我想知道是否可以将此语言功能添加到在 CLR 上运行的其他语言(如 C#)，或者此功能是否仅适用于更实用/更少 OO 的编程风格？

Answer 1

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

我不是元编程专家，但@SK-logic 问为什么不用通用的编译时元编程系统，我会尽力回答。我不认为您可以使用元编程轻松实现 F# 类型提供程序的功能，因为 F# 类型提供程序在设计时可能是惰性的和动态交互的。让我们举一个 Don 在他早期的视频中演示过的例子:Freebase类型提供者。 Freebase 有点像一个模式化的、可编程的维基百科，它拥有关于一切的数据。所以你最终可以按照以下方式编写代码

for e in Freebase.Science.``Chemical Elements`` do
    printfn "%d: %s - %s" e.``Atomic number`` e.Name e.Discoverer.Name

或诸如此类的东西(我手边没有确切的代码)，但可以轻松编写代码来获取有关棒球统计数据的信息，或者当著名 Actor 进入戒毒所时，或者通过以下方式获得的无数其他类型的信息免费基地。

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

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

(也许你现在可以用今天的一些元编程工具来做到这一点，我不知道，但我很久以前在学校学到的那些东西不能轻易地处理这个。)