blocks|key|4076556|text|我没有看到任何技术原因，为什么不能将类型提供程序之类的东西添加到C#或类似的语言中。使添加类型提供程序变得困难的唯一语言系列(与F#中的方式类似)是动态类型语言。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4076557|F#类型提供程序依赖于这样一个事实，即提供程序生成的类型信息可以很好地在程序中传播，并且编辑器可以使用它们来显示有用的IntelliSense。在动态类型语言中，这将需要更复杂的集成开发环境支持(动态语言的“类型提供程序”仅限于集成开发环境或IntelliSense)。|4076558|为什么它们被直接实现为F#的一个特性？我认为元编程系统必须非常复杂(请注意，类型实际上并不是生成的)才能支持它。使用它可以完成的其他事情对F#语言的贡献不会太大(它们只会使它变得太复杂，这是一件坏事)。但是，如果您具有某种编译器可扩展性，您可能会得到类似的结果。|4076559|事实上，我认为这就是C#团队未来将如何添加类似类型提供程序的东西(他们已经讨论了一段时间的编译器可扩展性)。|4076560|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

I don't see any technical reason why something like type providers couldn't be added to C# or similar languages. The only family of langauges that make it difficult to add type providers (in a similar way as in F#) are dynamically typed languages.

F# type providers rely on the fact that the type information that are generated by the provider nicely propagate through the program and the editor can use them to show useful IntelliSense. In dynamically typed languages, this would require more elaborate IDE support (and "type providers" for dynamic langauges reduce to just IDE or IntelliSense).

Why are they implemented directly as a feature of F#? I think the meta-programming system would have to be really complex (note that the types are not actually generated) to support this. The other things that could be done using it wouldn't contribute to the F# language that much (they would only make it too complex, which is a bad thing). However, you could get similar thing if you had some sort of compiler extensibility. 

In fact, I think this is how the C# team will add something like type providers in the future (they talked about compiler extensibility for some time now).

blocks|key|2461436|text|正如Tomas所说，理论上将这种特性添加到任何静态类型的语言中是很简单的(尽管仍然有很多繁琐的工作)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2461437|我不是元编程专家，但@SK-logic问为什么不使用通用的编译时元编程系统，我将尝试回答。我不认为您可以使用元编程轻松实现使用F#类型提供程序所能做的事情，因为F#类型提供程序在设计时可能是惰性的和动态交互的。让我们举一个例子，唐在他之前的一个视频中演示了:一个Freebase类型的提供者。Freebase有点像一个系统化的，可编程的维基百科，它有关于所有东西的数据。因此，您可以像下面这样编写代码：|offset|length|2461438|for+e+in+Freebase.Science.``Chemical+Elements``+do
++++printfn+"%25d:+%25s+-+%25s"+e.``Atomic+number``+e.Name+e.Discoverer.Name|code-block|syntax|javascript|2461439|或者诸如此类的东西(我手头没有确切的代码)，但同样容易编写代码来获取有关棒球统计数据的信息，或者著名演员在戒毒所的时间，或者可以通过Freebase获得的无数其他类型的信息。|2461440|从实现的角度来看，为所有Freebase生成模式并预先将其带入.NET是不可行的；您不能只在一开始就执行一个编译时步骤来设置所有这一切。您可以对小型数据源执行此操作，事实上，许多其他类型提供程序都使用此策略，例如，SQL类型提供程序指向数据库，并为该数据库中的所有类型生成.NET类型。但是这种策略对像Freebase这样的大型云数据存储不起作用，因为有太多相互关联的类型(如果您尝试为所有Freebase生成.NET元数据，您会发现有如此之多的类型(其中一个是带有AtomicNumber和Discoverer的ChemicalElement，以及Name和许多其他字段，但实际上有数百万这样的类型)，以至于您需要比32位.NET进程可用的更多的内存来表示整个类型架构。|style|CODE|2461441|因此，类型提供程序策略是一种允许类型提供程序按需提供信息的F#体系结构，在设计时在集成开发环境中运行。例如，在您键入Freebase.Science.之前，类型提供程序不需要知道科学类别下的实体，但是一旦您在Science之后按下.，类型提供程序就可以查询API，以了解整个模式的一个更高级别，以了解在科学下存在哪些类别，其中一个类别是ChemicalElements。然后，当您尝试“点进”其中一个元素时，它会发现元素有原子序号之类的。因此，类型提供程序懒惰地从整个模式中获取足够的内容，以处理用户恰好在那个时刻输入编辑器的确切代码。因此，用户仍然可以自由地探索信息宇宙的任何部分，但任何一个源代码文件或交互式会话都只会探索可用内容的一小部分。当需要编译/codegen时，编译器只需要生成足够的代码来容纳用户在其代码中实际使用的位，而不是潜在的巨大运行时位来提供与整个数据存储对话的可能性。|2461442|(也许你现在可以用现在的一些元编程工具做到这一点，我不知道，但是我很久以前在学校学到的那些工具不能很容易地处理这个问题。)|2461443|entityMap|0|LINK|mutability|MUTABLE|url|http://www.freebase.com/^0|0|3N|8|0|0|0|0|6H|C|6U|A|75|F|7N|4|0|1M|H|2W|7|37|1|4O|G|0|0^^$0|@$1|2|3|4|5|6|7|12|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|13|8|@]|9|@$D|14|E|15|1|16]]|A|$]]|$1|F|3|G|5|H|7|17|8|@]|9|@]|A|$I|J]]|$1|K|3|L|5|6|7|18|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|19|8|@$D|1A|E|1B|O|P]|$D|1C|E|1D|O|P]|$D|1E|E|1F|O|P]|$D|1G|E|1H|O|P]]|9|@]|A|$]]|$1|Q|3|R|5|6|7|1I|8|@$D|1J|E|1K|O|P]|$D|1L|E|1M|O|P]|$D|1N|E|1O|O|P]|$D|1P|E|1Q|O|P]]|9|@]|A|$]]|$1|S|3|T|5|6|7|1R|8|@]|9|@]|A|$]]|$1|U|3|-4|5|6|7|1S|8|@]|9|@]|A|$]]]|V|$W|$5|X|Y|Z|A|$10|11]]]]

As Tomas says, it is theoretically straightforward to add this kind of feature to any statically-typed language (though still a lot of grunt-work).

I am not a meta-programming expert, but @SK-logic asks why not a general compile-time meta-programming system instead, and I shall try to answer. I don't think you can easily achieve what you can do with F# type providers using meta-programming, because F# type providers can be lazy and dynamically interactive at design-time. Let's give an example that Don has demo-ed in one of his earlier videos: a <a href="http://www.freebase.com/" rel="nofollow">Freebase</a> type provider. Freebase is kind of like a schematized, programmable wikipedia, it has data on everything. So you can end up writing code along the lines of

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

or whatnot (I don't have the exact code offhand), but just as easily write code that gets information about baseball statistics, or when famous actors have been in drug rehab facilities, or a zillion other types of information available through Freebase.

From an implementation point-of-view, it is infeasible to generate a schema for all of Freebase and bring it into .NET a-priori; you can't just do one compile-time step at the beginning to set all this up. You can do this for small data sources, and in fact many other type providers use this strategy, e.g. a SQL type provider gets pointed at a database, and generates .NET types for all the types in that database. But this strategy does not work for large cloud data stores like Freebase, because there are too many interrelated types (if you tried to generate .NET metadata for all of Freebase, you'd find that there are so many millions of types (one of which is <code>ChemicalElement</code> with <code>AtomicNumber</code> and <code>Discoverer</code> and <code>Name</code> and many other fields, but there are literally millions of such types) that you need more memory than is available to a 32-bit .NET process just to represent the entire type schema.

So the F# type-provider strategy is an API architecture that allows type providers to supply information on-demand, running at design-time within the IDE. Until you type e.g. <code>Freebase.Science.</code>, the type provider does not need to know about the entities under the science categories, but once you do press <code>.</code> after <code>Science</code>, then the type provider can go and query the APIs to learn one-more-level of the overall schema, to know what categories exist under Science, one of which is <code>ChemicalElements</code>. And then as you try to "dot into" one of those, it will discover that elements have atomic numbers and what-not. So the type provider lazily fetches just enough of the overall schema to deal with the exact code the user happens to be typing into the editor at that moment in time. As a result, the user still has the freedom to explore any part of the universe of information, but any one source code file or interactive session will only explore a tiny fraction of what is available. When it comes time to compile/codegen, the compiler need only generate enough code to accomodate exactly the bits that the user has actually used in his code, rather than the potentially huge runtime bits to afford the possibility of talking to the whole data store.

(Maybe you can do that with some of today's meta-programming facilities now, I don't know, but the ones I learned about in school a long while back could not have easily handled this.)

blocks|key|2461495|text|正如Brian和Tomas指出的那样，这个特性没有什么特别的“功能性”。这只是一种向编译器提供元数据的特别巧妙的方式。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2461496|C#设计团队已经考虑这样的想法很长一段时间了。在我加入C#团队的几年前，有一个提议是关于一种将被称为“类型蓝图”(或类似的东西)的特性，通过该特性，C#编译器可以使用XML文档、XML+schema和提供类型元数据的自定义代码的组合。我不记得细节了，显然，它从来没有实现过。(尽管它确实影响了Visual+Studio+Tools+for+Office+document+format的设计和实现，我当时正在从事这项工作。)|2461497|无论如何，我们目前还没有计划在C#中添加这样的功能，但我们正怀着极大的兴趣关注它是否能很好地解决F#的客户问题。|2461498|(和往常一样，Eric对未宣布的和完全假设的产品未来可能的功能的思考仅用于娱乐目的。)|2461499|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

As Brian and Tomas point out, there's nothing particularly "functional" about this feature. It's just a particularly slick way to provide metadata to the compiler.

The C# design team has been kicking around ideas like this for a long time. There was a proposal a few years before I joined the C# team for a feature that was going to be called "type blueprints" (or something like that) whereby a combination of XML documents, XML schema and custom code that proffered up type metadata could be used by the C# compiler. I don't recall the details and it never came to fruition, obviously. (Though it did influence the design and the implementation of the Visual Studio Tools for Office document format, which I was working on at the time.)

In any event, we have no plans on the immediate horizon for adding such a feature to C#, but we are watching with great interest to see if it does a good job of solving customer problems in F#.

(As always, Eric's musings about possible future features of unnannounced and entirely hypothetical products are for entertainment purposes only.)

F# 3.0 has added <a href="http://msdn.microsoft.com/en-us/library/hh156509%28v=VS.110%29.aspx" rel="noreferrer">type providers</a>.

I wonder if it is possible to add this language feature to other languages running on the CLR like C# or if this feature only works well in a more functional/less OO programming style?

Which language idioms/paradigms/features make it hard to add support for "type providers"?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

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

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

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

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