Post 3123420 by veer66@toot.veer66.rocks
(DIR) More posts by veer66@toot.veer66.rocks
(DIR) Post #3123420 by veer66@toot.veer66.rocks
2019-01-19T01:29:17.093517Z
0 likes, 0 repeats
I feel that I understand a little bit more about Applicative. Maybe my problem is not about its concept. I just cannot parse Haskell code and symbol like <*> makes me confused.https://users.rust-lang.org/t/monads-and-functors-and-applicatives-explained-badly-in-rust/15187ภาพ.pngภาพ.png
(DIR) Post #3124194 by amiloradovsky@functional.cafe
2019-01-19T02:07:42Z
1 likes, 0 repeats
@veer66 Call me stubborn, but I still don't understand what all these super-abstract type-classes bring to the table, besides their definitions and the sheer confusion.And Rust's syntax for this is even more impenetrable than I thought it can possibly be…
(DIR) Post #3124377 by amiloradovsky@functional.cafe
2019-01-19T02:11:34Z
1 likes, 0 repeats
@veer66 Call me stubborn, but I still don't understand what all these super-abstract type-classes bring to the table, besides their definitions and the sheer confusion.And #Rust's syntax for this is even more impenetrable than I thought it can possibly be…
(DIR) Post #3124534 by kwarrtz@mathstodon.xyz
2019-01-19T02:21:17Z
1 likes, 1 repeats
@amiloradovsky @veer66 Rust doesn't have higher order typeclasses, so it has no applicative functors in the Haskell sense. What are you referring to here?
(DIR) Post #3124556 by veer66@toot.veer66.rocks
2019-01-19T02:22:33.831981Z
0 likes, 0 repeats
@kwarrtz @amiloradovsky So I still don't understand anything.
(DIR) Post #3125191 by amiloradovsky@functional.cafe
2019-01-19T02:26:14Z
0 likes, 0 repeats
@kwarrtz @veer66 I'm not sure what Rust does have, I only assumed the code on the pictures defines the same thing.
(DIR) Post #3125192 by kwarrtz@mathstodon.xyz
2019-01-19T02:49:05Z
1 likes, 0 repeats
@amiloradovsky @veer66 Ah, so it looks like the Rust snippet there is using some sort of unstable or experimental features to get higher kinded types. As for Andrew's original criticism, I find the abstraction very useful and convenient, but I imagine it's largely a personal preference/style thing. In many cases, I'll point out, abstraction also improves efficiency and safety, but I'm not going to make a claim as to whether that's the case here specifically.
(DIR) Post #3125298 by kwarrtz@mathstodon.xyz
2019-01-19T02:51:54Z
1 likes, 0 repeats
@amiloradovsky @veer66 As for Haskell's syntax, I know there's some debate around this. Binary combinators are very useful and concise, but there's a question about whether to use symbols or words in infix position. I think symbols are easier to scan and parse once you're used to them, but I certainly understand the accessibility complaint.
(DIR) Post #3125768 by amiloradovsky@functional.cafe
2019-01-19T03:10:15Z
1 likes, 0 repeats
@kwarrtzI'm not sure what exactly people mean by HKT, in terms of universes. "Kind" seems to be an ad-hoc term, introduced for the purpose of deception… WRT abstraction in general: I agree, it usually is helpful. But I guess I haven't seen a convincing example of helpfulness of these particular abstractions.WRT the syntax and conventions: it is wiser to prioritize the reader's convenience over the writer's, not vice versa. Cryptic code is gate-keeping.@veer66
(DIR) Post #3125769 by kwarrtz@mathstodon.xyz
2019-01-19T03:18:23Z
1 likes, 0 repeats
@amiloradovsky @veer66 When I said I thought symbols were easier to scan, I meant that as a reader not a writer. The term “kind” does have a well defined meaning in type theory. It is, roughly speaking, the type of type constructors. In most languages there’s only a single kind, usually denoted *. Haskell, however, has higher kinds, which means type constructors can be functions which take a type, and so have the kind * -> *. (1/2)
(DIR) Post #3125770 by kwarrtz@mathstodon.xyz
2019-01-19T03:20:24Z
1 likes, 1 repeats
@amiloradovsky @veer66 This is similar to generics in other languages like Rust, but the important difference here is that you can have a typeclass over an unapplied higher kinder type constructor in Haskell, but you can’t do the same with traits in Rust. Functor, Applicative and Monad are the typical examples of type classes on HKTs, which is why I was confused about how Rust could have an Applicative trait.
(DIR) Post #3125824 by veer66@toot.veer66.rocks
2019-01-19T03:25:45.060705Z
0 likes, 0 repeats
@kwarrtz @amiloradovsky tbh I have to study about "kinder" first. I am following a tutorial, when I reach this part, I will ping you.https://www.seas.upenn.edu/~cis194/fall16/
(DIR) Post #3125936 by kwarrtz@mathstodon.xyz
2019-01-19T03:30:40Z
1 likes, 0 repeats
@veer66 You may not get to kinds in that class actually. It isn’t really something you have to worry about when writing Haskell, it’s more of a topic for language design. As long as you understand the concept of a type constructor which takes other types as an argument (which you’ll definitely cover in the section on functors) you shouldn’t need to know the formalities. Definitely feel free to ping me about Haskell/FP stuff in general though.
(DIR) Post #3125967 by veer66@toot.veer66.rocks
2019-01-19T03:36:12.030271Z
0 likes, 0 repeats
@kwarrtz I try to get used to Haskell syntax and maybe terms.
(DIR) Post #3125982 by TheAspiringHacker@functional.cafe
2019-01-19T03:30:58Z
1 likes, 1 repeats
@veer66 A kind is basically the arity of a type constructor. Type constructors of kind * are types (e.g. Int, ()). Type constructors of kind * -> * are functions from types to types (e.g. Maybe, []). Type constructors can take multiple arguments, and they are curried. (e.g. Either, which has kind * -> * -> *). The argument can also be a type constructor itself (e.g. something of kind (* -> *) -> * -> *). Think of it as like the "type" of a type.
(DIR) Post #3126369 by kwarrtz@mathstodon.xyz
2019-01-19T03:32:54Z
1 likes, 0 repeats
@TheAspiringHacker @veer66 This gets a little confusing because people often consider lifetimes in Rust to have their own (atomic) kind. I don’t know if this is sound from a type theoretical point of view though
(DIR) Post #3126402 by amiloradovsky@functional.cafe
2019-01-19T03:34:38Z
1 likes, 0 repeats
@kwarrtz- The scanning argument kind of makes sense. Still, maybe I should speak about newcomers and establishment instead.- But what "type of type constructors" ever means? Type constructors are essentially abstracted away functions, returning an element of the type they construct.- I could as well define these type-classes as signatures for parametric modules and be fine, no?@veer66
(DIR) Post #3126419 by kwarrtz@mathstodon.xyz
2019-01-19T03:42:05Z
1 likes, 1 repeats
@amiloradovsky @veer66 Perhaps. (I don’t know much ML, which is I think what you’re referring to here? Haskell certainly doesn’t have parametrized modules.) Kinds are just a concept people use to reason formally about programming languages. It doesn’t mean that’s how you personally have to conceptualize these ideas. Thinking of them as functions that take and return types usually works just fine.