开关/模式匹配的想法

Question

我最近一直在关注F＃，虽然我不太可能在不久的将来跳过障碍，但它肯定会突出一些C＃（或图书馆支持）可以让生活更轻松的领域。

特别是，我正在考虑F＃的模式匹配功能，它允许非常丰富的语法 - 比当前的开关/条件C＃等价物更具表现力。我不会试图给出一个直接的例子（我的F＃不符合它），但简而言之它允许：

• 按类型匹配（对受歧视的联合进行全覆盖检查）[请注意，这也会推断出绑定变量的类型，给予成员访问权等）
• 匹配谓词
• 以上的组合（可能还有一些我不知道的其他情景）

虽然C＃最终可以借用[ahem]丰富的一些内容，但是在过渡期间我一直在研究可以在运行时做些什么 - 例如，将一些对象拼凑到一起相当容易允许：

var getRentPrice = new Switch<Vehicle, int>()
        .Case<Motorcycle>(bike => 100 + bike.Cylinders * 10) // "bike" here is typed as Motorcycle
        .Case<Bicycle>(30) // returns a constant
        .Case<Car>(car => car.EngineType == EngineType.Diesel, car => 220 + car.Doors * 20)
        .Case<Car>(car => car.EngineType == EngineType.Gasoline, car => 200 + car.Doors * 20)
        .ElseThrow(); // or could use a Default(...) terminator

其中getRentPrice是Func＆lt; Vehicle，int＆gt;。

[注意 - 这里的Switch / Case可能是错误的术语......但它显示了这个想法]

对我而言，这比使用重复的if / else或复合三元条件（对于非平凡的表达式变得非常混乱 - 括号丰富）的等价物要清楚得多。它还避免了 lot 的转换，并允许简单扩展（直接或通过扩展方法）到更具体的匹配，例如与VB Select相当的InRange（...）匹配。 ..Case“x To y”用法。

我只想判断人们是否认为上述结构有很多好处（在没有语言支持的情况下）？

另外请注意，我一直在玩上述3种变体：

• a Func＆lt; TSource，TValue＆gt;用于评估的版本 - 与复合三元条件陈述相当
• 动作＆lt; TSource＆gt;版本 - 与if / else if / else if / else if / else
相当
• 表达式＆lt; Func＆lt; TSource，TValue＆gt;＆gt; version - 作为第一个，但可由任意LINQ提供程序使用

此外，使用基于表达式的版本可以实现表达式树重写，基本上将所有分支内联到单个复合条件表达式中，而不是使用重复调用。我最近没有检查，但在一些早期的Entity Framework构建中，我似乎记得这是必要的，因为它不太喜欢InvocationExpression。它还允许更有效地使用LINQ到对象，因为它避免了重复的委托调用 - 测试显示匹配如上所述（使用表单形式）以相同的速度执行[事实上稍微快一点]与等效的C＃相比复合条件语句。为了完整起见，Func＆lt; ...＆gt;基于版本的版本占C＃条件语句的4倍，但仍然非常快，在大多数用例中不太可能成为主要瓶颈。

我欢迎上述任何想法/输入/批评/等（或者更丰富的C＃语言支持的可能性......这里希望;-p）。

Answer 1

巴特德斯梅特的excellent blog有8部分关于完成你所描述的内容。找到第一部分here。

Answer 2

在尝试在C＃中做这样的“功能性”事情之后（甚至尝试了一本关于它的书），我得出的结论是，除了少数例外，这些事情没有太多帮助。

主要原因是F＃等语言通过真正支持这些功能获得了很多力量。不是“你能做到”，而是“它很简单，很明显，它是预期的”。

例如，在模式匹配中，您可以让编译器告诉您是否存在不完整的匹配，或者是否永远不会遇到其他匹配。对于开放式类型，这不太有用，但是当匹配一个有区别的联合或元组时，它非常漂亮。在F＃中，你希望人们模式匹配，它立即有意义。

“问题”是，一旦你开始使用一些功能概念，想要继续是很自然的。但是，利用C＃中的元组，函数，部分方法应用程序和currying，模式匹配，嵌套函数，泛型，monad支持等，很快就会非常难看。这很有趣，一些非常聪明的人在C＃中做了一些非常酷的事情，但实际上使用感觉很重。

我最终在C＃中经常使用（跨项目）：

• 序列函数，通过IEnumerable的扩展方法。 ForEach或Process之类的事情（“应用”？ - 对枚举的序列项执行操作）适合，因为C＃语法很好地支持它。
• 摘要常见的陈述模式。复杂的try / catch / finally块或其他涉及的（通常很通用的）代码块。扩展LINQ-to-SQL也适用于此处。
• 元组，在某种程度上。

**但请注意：缺乏自动泛化和类型推断确实会妨碍使用这些功能。 **

所有这些都说，就像其他人提到的那样，在一个小团队中，出于特定目的，是的，如果你坚持使用C＃，也许他们可以提供帮助。但根据我的经验，他们通常觉得比他们的价值更麻烦 - YMMV。

其他一些链接：

• Mono.Rocks playground有许多类似的东西（以及非功能性编程但有用的附加内容）。
• Luca Bolognese's functional C# library
• Matthew Podwysocki's functional C# on MSDN

Answer 3

可以说C＃不能简单地打开类型的原因是因为它主要是一种面向对象的语言，而在面向对象的术语中执行此操作的“正确”方法是定义GetRentPrice方法在Vehicle上并在派生类中覆盖它。

也就是说，我花了一些时间玩多范式和功能语言，如F＃和Haskell，它们具有这种能力，而且我遇到过很多以前会有用的地方（例如，当你没有编写你需要打开的类型，所以你不能在它们上实现虚拟方法）这是我欢迎使用语言和歧视的工会。

[编辑：删除部分关于性能，因为Marc表示可能会被短路]

另一个潜在的问题是可用性问题 - 从最终调用中可以清楚地看出，如果匹配无法满足任何条件会发生什么，但如果匹配两个或更多条件，那么行为是什么？它应该抛出异常吗？它应该返回第一个还是最后一个匹配？

我倾向于使用一种解决这类问题的方法是使用一个字典字段，其类型为键，lambda为值，使用对象初始化器语法构造非常简洁;但是，这仅考虑具体类型，并且不允许其他谓词，因此可能不适合更复杂的情况。 [附注 - 如果你看一下C＃编译器的输出，它经常将switch语句转换为基于字典的跳转表，所以似乎没有理由不支持切换类型]

Answer 4

我不认为这些类型的库（其作用类似于语言扩展）可能会获得广泛接受，但它们很有趣，并且对于在特定领域工作的小团队非常有用。例如，如果您正在撰写大量的“业务规则/逻辑”来执行任意类型的测试，例如this和whatnot，我可以看到它会如何方便。

我不知道这是否有可能是C＃语言功能（看起来很可疑，但谁可以看到未来？）。

作为参考，相应的F＃约为：

let getRentPrice (v : Vehicle) = 
    match v with
    | :? Motorcycle as bike -> 100 + bike.Cylinders * 10
    | :? Bicycle -> 30
    | :? Car as car when car.EngineType = Diesel -> 220 + car.Doors * 20
    | :? Car as car when car.EngineType = Gasoline -> 200 + car.Doors * 20
    | _ -> failwith "blah"

假设您已经按照

的方式定义了一个类层次结构

type Vehicle() = class end

type Motorcycle(cyl : int) = 
    inherit Vehicle()
    member this.Cylinders = cyl

type Bicycle() = inherit Vehicle()

type EngineType = Diesel | Gasoline

type Car(engType : EngineType, doors : int) = 
    inherit Vehicle()
    member this.EngineType = engType
    member this.Doors = doors

Answer 5

我知道这是一个古老的话题，但在c＃7中你可以做到：

switch(shape)
{
    case Circle c:
        WriteLine($"circle with radius {c.Radius}");
        break;
    case Rectangle s when (s.Length == s.Height):
        WriteLine($"{s.Length} x {s.Height} square");
        break;
    case Rectangle r:
        WriteLine($"{r.Length} x {r.Height} rectangle");
        break;
    default:
        WriteLine("<unknown shape>");
        break;
    case null:
        throw new ArgumentNullException(nameof(shape));
}

Answer 6

要回答你的问题，是的，我认为模式匹配句法结构很有用。我想在C＃中看到语法支持。

这是我的一个类的实现，它提供（几乎）与你描述的语法相同的语法

public class PatternMatcher<Output>
{
    List<Tuple<Predicate<Object>, Func<Object, Output>>> cases = new List<Tuple<Predicate<object>,Func<object,Output>>>();

    public PatternMatcher() { }        

    public PatternMatcher<Output> Case(Predicate<Object> condition, Func<Object, Output> function)
    {
        cases.Add(new Tuple<Predicate<Object>, Func<Object, Output>>(condition, function));
        return this;
    }

    public PatternMatcher<Output> Case<T>(Predicate<T> condition, Func<T, Output> function)
    {
        return Case(
            o => o is T && condition((T)o), 
            o => function((T)o));
    }

    public PatternMatcher<Output> Case<T>(Func<T, Output> function)
    {
        return Case(
            o => o is T, 
            o => function((T)o));
    }

    public PatternMatcher<Output> Case<T>(Predicate<T> condition, Output o)
    {
        return Case(condition, x => o);
    }

    public PatternMatcher<Output> Case<T>(Output o)
    {
        return Case<T>(x => o);
    }

    public PatternMatcher<Output> Default(Func<Object, Output> function)
    {
        return Case(o => true, function);
    }

    public PatternMatcher<Output> Default(Output o)
    {
        return Default(x => o);
    }

    public Output Match(Object o)
    {
        foreach (var tuple in cases)
            if (tuple.Item1(o))
                return tuple.Item2(o);
        throw new Exception("Failed to match");
    }
}

以下是一些测试代码：

    public enum EngineType
    {
        Diesel,
        Gasoline
    }

    public class Bicycle
    {
        public int Cylinders;
    }

    public class Car
    {
        public EngineType EngineType;
        public int Doors;
    }

    public class MotorCycle
    {
        public int Cylinders;
    }

    public void Run()
    {
        var getRentPrice = new PatternMatcher<int>()
            .Case<MotorCycle>(bike => 100 + bike.Cylinders * 10) 
            .Case<Bicycle>(30) 
            .Case<Car>(car => car.EngineType == EngineType.Diesel, car => 220 + car.Doors * 20)
            .Case<Car>(car => car.EngineType == EngineType.Gasoline, car => 200 + car.Doors * 20)
            .Default(0);

        var vehicles = new object[] {
            new Car { EngineType = EngineType.Diesel, Doors = 2 },
            new Car { EngineType = EngineType.Diesel, Doors = 4 },
            new Car { EngineType = EngineType.Gasoline, Doors = 3 },
            new Car { EngineType = EngineType.Gasoline, Doors = 5 },
            new Bicycle(),
            new MotorCycle { Cylinders = 2 },
            new MotorCycle { Cylinders = 3 },
        };

        foreach (var v in vehicles)
        {
            Console.WriteLine("Vehicle of type {0} costs {1} to rent", v.GetType(), getRentPrice.Match(v));
        }
    }

Answer 7

模式匹配（如here所述），其目的是根据类型规范解构值。但是，C＃中类（或类型）的概念与您不一致。

多范式语言设计没有错，相反，在C＃中使用lambdas非常好，而Haskell可以做一些必要的事情。 IO。但它不是一个非常优雅的解决方案，而不是Haskell方式。

但是由于顺序过程编程语言可以用lambda演算来理解，而C＃恰好适合顺序过程语言的参数，所以它非常适合。但是，从Haskell的纯函数上下文中获取一些东西，然后将该特性放入一种不纯粹的语言中，那就是这样做，并不能保证更好的结果。

我的观点是，模式匹配的关键是与语言设计和数据模型相关联。话虽如此，我不认为模式匹配是C＃的一个有用特性，因为它不能解决典型的C＃问题，也不适合命令式编程范例。

Answer 8

恕我直言，这样做的OO方式是访客模式。您的访问者成员方法只是作为案例构造，您让语言本身处理适当的调度，而不必“窥视”类型。

Answer 9

虽然打开类型不是很“C-sharpey”，但我知道构造在一般使用中会非常有用 - 我至少有一个可以使用它的个人项目（尽管它可管理的ATM）。是否有很多编译性能问题，表达式树重写？

Answer 10

我认为这看起来非常有趣（+1），但有一点需要注意：C＃编译器非常擅长优化switch语句。不仅仅是为了短路 - 你会得到完全不同的IL，具体取决于你有多少箱子等等。

您的具体示例确实做了一些我觉得非常有用的事情 - 没有类似于case的语法，因为（例如）typeof(Motorcycle)不是常量。

这在动态应用程序中变得更有趣 - 您的逻辑可以很容易地由数据驱动，从而实现“规则引擎”样式执行。

Answer 11

您可以使用我编写的名为OneOf

的库来实现您的目标

switch（以及if和exceptions as control flow）的主要优势在于它是编译时安全的 - 没有默认处理程序或通过

   OneOf<Motorcycle, Bicycle, Car> vehicle = ... //assign from one of those types
   var getRentPrice = vehicle
        .Match(
            bike => 100 + bike.Cylinders * 10, // "bike" here is typed as Motorcycle
            bike => 30, // returns a constant
            car => car.EngineType.Match(
                diesel => 220 + car.Doors * 20
                petrol => 200 + car.Doors * 20
            )
        );

它在Nuget上，目标是net451和netstandard1.6