【问题标题】:Comparison Of Nemerle and F# For Functional On .NetNemerle 和 F# 在 .Net 上的功能比较
【发布时间】:2010-08-27 21:15:12
【问题描述】:

社区 Wiki 问题:

根据这个问题:What are the benefits of using Scala in .Net? 想到另一个问题。任何人都可以列出Nemerle 和 F# 在 .Net 平台上进行功能开发的比较优势(和劣势)吗?我只是顺便看了看Nemerle。听起来它与 F# 在同一个球场上发挥作用,所以我想知道除了明显的语法差异和 F# 得到微软支持的巨大优势之外还有什么不同。

【问题讨论】:

    标签: .net f# functional-programming nemerle


    【解决方案1】:

    我接触过这两种语言,我对 Nemerle 的印象简要如下:(我假设大多数观众都熟悉 F#,而 Nemerle 不太受欢迎,所以为了公平起见,我会稍微介绍一下更多):

    • F# 社区相当大,并且由于大量的博文、文章等而不断增长。而且它分布在各个国家。相反,Nemerle 爱好者基本上都是讲俄语的,并且专注于RSDN.ru 网站。
    • 对于具有类 C 语言背景的开发人员来说,Nemerle 语法对 IMO 更加友好。
    • Nemerle(以及 F#)具有类型推断功能。 Nemerle 中的类型推断机制与方法体(局部函数、变量等)绑定,与 F# 的全局类型推断作用域相对。但是 Nemerle 编译器不强制执行任何特定的编写代码来辅助类型推断机制的习惯用法。

    F#

    open System.Text
    
    let l = [1; 2; 3]
    let r1 = l |> List.fold(fun (sb : StringBuilder) v -> sb.Append(v).AppendLine()) (StringBuilder()) // type annotation is required on the function argument
    let r2 = (StringBuilder(), l) ||> List.fold(fun sb v -> sb.Append(v).AppendLine()) //here compiler can infer type of State parameter 
    

    内马尔

    using System.Console; 
    using System.Collections.Generic; 
    using System.Text; 
    
    def l = [1,2,3]; 
    def res = l.FoldLeft(StringBuilder(), (v, acc) => acc.Append(v).AppendLine()); 
    WriteLine($"Result:\n$res"); 
    
    def d = Dictionary(); // generic parameters are absent (even placeholders!!!) 
    d.Add(1, "!"); 
    WriteLine(d.GetType()); // System.Collections.Generic.Dictionary`2[System.Int32,System.String] 
    

    您还可能注意到 Nemerle 编译器的另一个特性——它可以从进一步的使用中推断出类型。 F# 使用基于 Hindley-Milner 算法的方法来推断类型,并尝试推断大多数通用类型。相反,Nemerle 从不推断多态类型,总是寻找最具体的类型。

    F#

    let addInt = (+) 5
    let addString = (+) "!!!"
    
    let run f x = f (f x) // ('T -> 'T) -> 'T -> 'T
    
    run addInt 5
    run addString "S"
    

    在相同条件下,Nemerle 将推断 run 的类型为 (int->int) * int -> int。

    关于 Nemerle 类型推断机制的更多细节可以在 Michal Moskal 的硕士论文中找到:Type Inference With Deferral

    • Nemerle 具有丰富的元编程功能。大多数语言控制结构,如循环、条件表达式、LINQ 支持、即将推出的解析功能包括 C# 源等等——所有这些都是使用宏创建的。可以在here 找到一个宏应用程序示例。顺便说一句,上面示例中具有 $ 语法的字符串格式化功能 - 也是内置宏。

    编辑:添加了稍大的样本

    using System.Console;
    using System.Collections.Generic;
    using System.Text;
    
    variant Expr
    {
      | Const { value : double }
      | Var { name : string }
      | Operation { id : string; left : Expr; right : Expr }
    
      public Eval(operations : Dictionary[string, double*double -> double], context : Dictionary[string, double]) : double
      {
        match(this)
        {
            | Const (value) => value
            | Var(name) => context[name]
            | Operation(id, left, right) => 
                def f = operations[id];
                f(left.Eval(operations, context), right.Eval(operations, context))
        }
      }
    }
    
    module Program
    {
        public Main() : void
        {
            def expr = 
                Expr.Operation(
                    "*",
                    Expr.Const(10),
                    Expr.Operation(
                    "+",
                    Expr.Var("n"),
                    Expr.Const(5)
                    )
                );
            def operations = Dictionary.[string, double * double -> double]();
            operations["+"] = (x, y) => x + y;
            operations["*"] = _ * _;
    
            def vars = Dictionary();
            vars["n"] = 3.0;
    
            def result = expr.Eval(operations, vars);
            WriteLine($"Result is $result");
        }
    }
    

    【讨论】:

      【解决方案2】:

      我对 Nemerle 知之甚少,但我认为它的一大特点是宏(类似于卫生的 Scheme 的快乐宏,而不是丑陋的 C 类宏)。我从来没有完全理解为什么人们如此喜欢宏,但话说回来,我从来没有理解为什么人们如此喜欢代数数据类型和模式匹配,直到我开始使用 F#。所以我怀疑,如果你喜欢宏,并且使用 .NET,那么你就是 Nemerle 的狂热粉丝。

      【讨论】:

      • 嗯,模式匹配。我想知道快乐宏这样的方案有多好吃。现在我必须在周末尝试 Nermerle。
      • Nemerle 宏基本上是编译器扩展。它们用于实现大多数语言结构,包括“if”语句和“for”循环、Linq 支持以及用于日志记录、分析、AOP 等的各种有用库。
      • “我从来没有完全理解为什么人们如此喜欢宏”。如果您了解 F#,请尝试 OCaml 的宏 (camlp4)。
      • “我从来没有完全理解为什么人们如此喜欢宏”。我发现了 Nemerle,因为我想知道我是否可以在 F# 中使用宏,所以也许我最终可以停止 OnPropertyChanged 的疯狂和混乱,它是如何用 UI 可见的类弄脏每个文件的。我已经厌倦了。我将拭目以待,看看这些代码重复的未来会怎样。
      猜你喜欢
      • 1970-01-01
      • 2016-08-13
      • 1970-01-01
      • 1970-01-01
      • 2013-02-26
      • 2012-03-27
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多