TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Functor-Oriented Programming

179 点作者 szatkus超过 7 年前

12 条评论

harveywi超过 7 年前
Seems to be similar to the direction taken by John De Goes (using algebras to describe your problem domain, building programs from those algebras via free monads&#x2F;applicatives&#x2F;etc., interpreting those programs using natural transformations). I think there is definitely something to this kind of thinking.<p>Both authors argue that modern programming languages do not have the best ergonomics for this style of programming, albeit it is at least possible to do most of it in languages such as Haskell and Scala.<p>1. Data Structures Are Antithetical to Functional Programming [<a href="http:&#x2F;&#x2F;degoes.net&#x2F;articles&#x2F;kill-data" rel="nofollow">http:&#x2F;&#x2F;degoes.net&#x2F;articles&#x2F;kill-data</a>]<p>2. A Modern Architecture for FP [<a href="http:&#x2F;&#x2F;degoes.net&#x2F;articles&#x2F;modern-fp" rel="nofollow">http:&#x2F;&#x2F;degoes.net&#x2F;articles&#x2F;modern-fp</a>]<p>3. Modern Functional Programming: Part 2 [<a href="http:&#x2F;&#x2F;degoes.net&#x2F;articles&#x2F;modern-fp-part-2" rel="nofollow">http:&#x2F;&#x2F;degoes.net&#x2F;articles&#x2F;modern-fp-part-2</a>]
评论 #15456965 未加载
评论 #15453681 未加载
评论 #15455069 未加载
评论 #15454197 未加载
fmap超过 7 年前
There is an easy design choice - which Haskell didn&#x27;t take - which would allow us to have transparent Identity functors, associative Compose and many others: Add a conversion rule to your language and don&#x27;t eagerly expand definitions at the type level.<p>For example, in Coq you would write<p><pre><code> Definition Identity a := a. Definition Compose F G a := F (G a). Instance: Functor Identity. Proof[...] </code></pre> and so on. This works, since explicit conversion during type checking allows you to associate type classes to otherwise transparent definitions.<p>Of course, this is no silver bullet and complicates other things. Everything works out beautifully though, if you combine conversion with bidirectional type checking, at the expense of less powerful type inference.
评论 #15457022 未加载
评论 #15452881 未加载
dbranes超过 7 年前
This is great. It&#x27;s essentially asking you to work in a 2-category[1], which, once you get used to it, is an amazingly intuitive way to make sense of constructions in ordinary 1-categories.<p>[1]<a href="https:&#x2F;&#x2F;ncatlab.org&#x2F;nlab&#x2F;show&#x2F;2-category" rel="nofollow">https:&#x2F;&#x2F;ncatlab.org&#x2F;nlab&#x2F;show&#x2F;2-category</a>
platz超过 7 年前
Gabriel Gonzalez: The functor design pattern<p><a href="http:&#x2F;&#x2F;www.haskellforall.com&#x2F;2012&#x2F;09&#x2F;the-functor-design-pattern.html" rel="nofollow">http:&#x2F;&#x2F;www.haskellforall.com&#x2F;2012&#x2F;09&#x2F;the-functor-design-patt...</a><p>is also a well-known post.
vog超过 7 年前
Pardon my ignorance, but can&#x27;t this be more easily translated into terms of (modern) object oriented programming, where you avoid mutating state?<p>Here, the &quot;natural transformation&quot; is a function that takes an input object which adheres to a specific interface (i.e. provides a set of specific methods), operates only on that input interface, and returns another object that conforms to the expected output interface.<p>Avoiding mutating state means that either those objects have no attributes, or that the state can only be set on construction. (In FP speak, this corresponds currying of common parameters. Or to an internal abstract type, if the constructor is private and you can only create it via a specific set of static methods).<p>Is this modern style of OOP equivalent to &quot;Functor-Oriented Programming&quot;, or am I missing something?
评论 #15457016 未加载
评论 #15456704 未加载
评论 #15456679 未加载
vittore超过 7 年前
I really want to see examples of this.
评论 #15452966 未加载
评论 #15452302 未加载
评论 #15453997 未加载
AlexCoventry超过 7 年前
Anyone got some good examples of this?<p>&gt; With functor oriented programming, polymorphism is not necessarily about using functions polymorphically. Instead, polymorphism provides correctness guarantees by ensuring that a particular function can only touch the specific layers of functors in its type signature and is independent of the rest of the data structure. One benefits from polymorphism even when a function is only ever invoked at a single type.
评论 #15457073 未加载
评论 #15456590 未加载
runeks超过 7 年前
It would be nice to know what kind of code OP writes. Ie. are we talking application code or library code, and if it&#x27;s libraries are we talking networking libraries, graphics libraries or math libraries?<p>Usually I find that Haskellers write very &quot;low-level&quot; code, ie. implement math abstractions or the like, while I prefer to write applications (in Haskell), where this abstraction technique may not be suitable.
评论 #15454523 未加载
评论 #15454403 未加载
评论 #15452904 未加载
highmastdon超过 7 年前
It&#x27;s not the same thing, but it triggered something. A programming language related is Koka (see: An overview of Koka: <a href="https:&#x2F;&#x2F;koka-lang.github.io&#x2F;koka&#x2F;doc&#x2F;kokaspec.html#sec-an-overview-of-koka" rel="nofollow">https:&#x2F;&#x2F;koka-lang.github.io&#x2F;koka&#x2F;doc&#x2F;kokaspec.html#sec-an-ov...</a>).<p>It&#x27;s basically a functional programming language where functions can be applied to a type. The type is then passed as the first parameter. So instead of `afunction(param1, param2)` you would do `param1.afunction(param2)`.<p>Example: (<a href="https:&#x2F;&#x2F;koka-lang.github.io&#x2F;koka&#x2F;doc&#x2F;kokaspec.html#sec-structs" rel="nofollow">https:&#x2F;&#x2F;koka-lang.github.io&#x2F;koka&#x2F;doc&#x2F;kokaspec.html#sec-struc...</a>)<p>struct person(age: int, name: string)<p>fun birthday(p: Person) { return p(age = p.age+1) }<p>val me = Person(27, &quot;Albert&quot;) &#x2F;&#x2F; { age: 27, name: &quot;Albert&quot; }<p>val meWithBirthday = me.birthday() &#x2F;&#x2F; { age: 28, name: &quot;Albert&quot; }
评论 #15454805 未加载
z3t4超过 7 年前
A strict type system makes sure your program is statically correct, and catches many bugs caused by the programmer. The real world though is dynamic and I prefer to check all input data at runtime, eg. each function check if what&#x27;s passed into it is correct. It not only catches a lot of bugs, those caused by the programmer <i>and</i> the ones caused by interacting with the outside word, it also makes the code easier to test. This probably sounds like I&#x27;m swearing in church to a Haskel programmer though.
评论 #15458456 未加载
Fire-Dragon-DoL超过 7 年前
Any chance someone can provide code examples, maybe in a bunch of different languages (elm, haskell and even js functional)? Would love to understand this more
dmitriid超过 7 年前
&gt; Instead of writing transformations between data structures, one writes natural transformations between functors, where a natural transformation between functors F and G is a polymorphic function of type forall a. F a -&gt; G a.<p>There&#x27;s nothing <i>natural</i> about this.<p>;)