PureScript中能否将ADT构造器直接作为类型使用？

这种设计思路绝非完全不值得采用，它是一类基于精度优先的设计权衡，只是需要和当前语言的类型系统能力匹配，不能和之前提到的类型类方案混为一谈。

当前遇到的限制本质 #

你现在碰到的签名无法编写的问题，核心来自传统ADT的设计约定：

• 在Haskell/PureScript这类语言的标准ADT实现中，Circle 仅属于Shape类型的值构造器，本身不是可独立标注的类型，因此没法直接把它写在函数的返回值位置。
• 你提到的把Shape改成类型类的方案，确实存在无法接受的硬伤：它会彻底破坏原有的封闭联合语义——你无法保证实现Shape类型类的类型永远只有Circle、Rectangle等四个，后续任何模块都能新增实现，模式匹配的穷尽性检查也会失效，本质上是把封闭枚举换成了开放接口，完全偏离了最初的建模目标。

不靠类型类也能实现“构造器即类型”的核心思路 #

要实现「每个构造器对应一个独立可用类型，同时保留Shape是封闭四元联合的语义」，根本不需要引入类型类，只需要对类型定义做一点点结构化调整：

1. 先把每个具体形状单独定义为独立的newtype，拥有自己的类型身份：

   newtype Circle = Circle { center :: Point, radius :: Number }
   newtype Rectangle = Rectangle { topLeft :: Point, width :: Number, height :: Number }
   newtype Line = Line { start :: Point, end :: Point }
   newtype Text = Text { origin :: Point, content :: String }
   

2. 再用原来的ADT定义把这些独立类型组成封闭联合，完全保留原有语义：

   data Shape
     = ShapeCircle Circle
     | ShapeRectangle Rectangle
     | ShapeLine Line
     | ShapeText Text
   

这种结构下，你想要的函数签名可以完全按照原写法落地：

boundingCircle :: Shape -> Circle
boundingBox :: Shape -> Rectangle

既没有类型类的开放性问题，也不会丢失模式匹配的穷尽检查能力，本质就是用零成本的样板代码，换来了“构造器可当独立类型使用”的能力。

这类设计的适用边界 #

把构造器对应的结构拆成独立类型的方案，从来不是普适的银弹，需要权衡收益和成本：

• 收益与适用场景：
  • 当业务逻辑中存在大量需要把具体形状作为独立类型处理的场景时，比如需要单独给圆写参数校验、给矩形写变换逻辑、函数接口需要明确返回某类具体形状时，拆分带来的类型精度收益远大于写样板代码的成本。
  • 可以避免之前常见的类型模糊问题：比如原来想表达“这个函数返回一个圆”，在纯ADT的定义里只能把返回值标为Shape，后续调用者没法从类型上知道返回值一定是圆，很容易在调用时漏匹配其他分支。
• 代价与不适用场景：
  • 存在构造器的“双重命名”冗余：原来只需要写Circle center r，拆分后构造联合值时需要写ShapeCircle (Circle { center, radius: r })，频繁构造值的场景下会显得啰嗦。
  • 从联合类型反向提取具体子类型时，需要额外写模式匹配的转换逻辑，没有原生把构造器当类型用那么顺畅。
  • 如果你的业务大部分时候都是把形状作为统一的联合类型处理，很少有单独操作某类形状的类型级需求，那直接用最开始的单ADT定义就足够，强行拆分就是过度设计。

对这种设计思路的最终判断 #

这种“将ADT构造器对应结构作为独立类型使用”的思路，本质是在建模时给不同粒度的语义匹配对应的类型身份，根本不是什么不值得采用的反模式。
实际上很多支持可辨识联合的现代语言已经把这个能力做进了原生类型系统，比如TypeScript里可以通过工具类型直接从联合类型里拆分出单个成员作为独立类型：

type Point = { x: number, y: number }
type Shape =
  | { kind: 'circle', center: Point, radius: number }
  | { kind: 'rect', topLeft: Point, width: number, height: number }
  | { kind: 'line', start: Point, end: Point }
  | { kind: 'text', origin: Point, content: string }

// 直接拆分出联合内的单个成员作为独立类型
type Circle = Extract<Shape, { kind: 'circle' }>
type Rectangle = Extract<Shape, { kind: 'rect' }>

这种原生拆分既保留了封闭联合的穷尽匹配能力，也不需要写额外的newtype样板，恰恰证明这种设计思路本身是完全成立的，只是在PureScript/Haskell这类传统ADT实现的语言里，需要少量手写代码来落地而已。

内容的提问来源于stack exchange，提问作者Mrk Sef