Here’s something fun. That is, you don’t need to know this, however it’s a fancy trick. How do you know that you’ve exhausted the possibilities of implementing some functions? You can use algebraic types for this.
You’ll see (Boolean -> Boolean) is 2^2 in algebraic type notation. This means there should be 4 possible ways to implement the function, plus getting stuck. Also, the type is isomorphic with 2*2. The * stands for product. That is we get the following truth table that tells the 4 possible way to implement our function.
This output is produced by this function
vvvvv vvvvv vvvvvvvvvvv
false false <==> const false
true false <==> not
false true <==> identity
true true <==> const true
Btw. I’m a bit frustrated about this. I appreciate this feedback but it took me a good while to understand how useful the things I’ve told about are and you’re outright rejecting it in this context.
I think you’re not reading my posts and I find that a bit rude. Sure I did not mention there’s a whole Wikipedia page on game semantics. If you read it you’ll find out there are amazing things that has been done with this approach. I would think it is an approachable way to teach semantics of functional programming languages, since they are closely related to formal logic. I even attempted to address the differences.
Now if we look at Elm. I acknowledge they’ve done pretty neat things there too. I really think their getting started documentation is brilliant. I love the interactive prompts that allow you immediately try out things while you read. I think that also worked on mobile. However, I am pissed about the unwillingness to address difficult things with fear that they’re alienating the audience by being too difficult to understand. That’s likely an one reason they dropped type classes despite how useful they are. If something’s useful then we’ll do best if we find out a good way to teach it.
Indeed, it is moreover quite conventional to note R to the power D the set of functions from D to R which has at least the advantage to remind that the number of such functions is #R to the power #D.
I think the game perspective can definitely be useful in some contexts, but in this particular case it’s pretty clear to me that it’s not appropriate. In particular, the OP has explicitly mentioned the kinds of resources they are interested in, and the things you’ve linked to are pretty much diametrically opposed to it in their approach. I don’t doubt your good intentions but I do think it does more harm than good to link to things like the Wikipedia page for type theory and a video of Wadler discussing the Curry-Howard isomorphism in response to queries like “I would like to be walked through building a web app step by step”; we’re trying to dispel the myth that Haskell and PureScript require a PhD in mathematics, not reinforce it.
All right, I think I see that in the first post now. I totally zoned out after reading he needs help with understanding what is a type. I’m sorry about that.
no problem. It’s true that doesn’t seem to mean much, but exhaustivity can make things easy to grasp for some beginners. For instance, prove the difference between
Here’s a video walkthrough on how to get started with the book, including how to grab all required dependencies, setup an IDE, and run the chapter tests. Hoping this lowers the barrier to entry.
Would this video be useful to include at the beginning of the getting started section? Any cleanup suggestions?
I also tag-teamed between the PureScript book and Learn you a Haskell when learning PureScript. Oftentimes when something in the PureScript book didn’t make sense right away, the description of the same concept in Learn you a Haskell would be more approachable.
I love the PureScript book as a general resource, but I think Learn you a Haskell is more targeted towards an audience that’s learning FP at the same time as learning the language. I bet there are some good Elm resources you could say the same thing about, though I don’t know much about Elm…
We could make a clone of LYAH and do some minor edits to the text and examples to make it target PureScript. The license allows creating derivatives. Would this be a useful resource?
Here’s a quick starting point with the intro rewritten as a proof-of-concept. https://lya.ps.ai/
See this strategy discussion in the repo for planning next steps.
I tried the same, but Learn You seems to be a better fit as a reference for those who understand functional programming and ML typing. I read it half a dozen times but still didn’t understand type classes vs type constructors, type instances, minimal type definitions, type inheritance and derivatives. I certainly didn’t understand how to make practical use of them. EG deriving enum and bounded to rotate and sort arrays of things by integer value.
It’s true that when I tried learning PureScript & Haskell, I was coming from a “mostly functional” background working with F# (which I learned from F# for fun and profit, though I don’t recommend that as a useful learning resource in this conversation). I am surprised though to hear that that Learn You a Haskell isn’t a good resource if you’re not familiar with FP. I’m not familiar with “Get Programming with Haskell,” but you think that’s a better resource if you’re coming from an imperative background?
That proof-of-concept is awesome! I’d definitely be interested in helping with the port if that’s something the community thinks would be a good learning resource for PureScript!
Since you know typescript, we can compare equivalent code in typescript and purescript to get you started.
function f<a, b>(x: a, y: b): string {
return "hello!"
}
f :: forall a b. a -> b -> String
f x y = "hello!"
forall is like the angle-brackets in TS where you declare your generics.
Maybe can be written in TS like this:
type Maybe<a> = { value: a | null }
function Just<a>(value: a): Maybe<a> {
return { value }
}
function Nothing<a>(): Maybe<a> {
return { value: null }
}
The point of Maybe in PS is that the compiler requires that you check whether it contains a value or not before trying to access it (you can bypass this check but not by accident which is important). This way you can’t accidentally try to reference a null and get a crash.
Hope this helps, if you have more questions, don’t hesitate! I personally think it might be useful to explain to non-FP programmers how FP works by comparing it to what they’re used to.
PureScript and Haskell didn’t click for me until I watched Bartosz Milewskis Category Theory tutorials on Youtube. But by then I had been doing F# for years so I was comfortable with immutability abd that type of thinking.
If you decide in the end that you going to pass on PureScript for now, I suggest you install the immutable tslint rules for TypeScript. This turns TypeScript into a decent functional programming language to help you learn the basics in an environment you’re already comfortable with.
This idea of meeting people where they’re coming from could be foregrounded more in the “Welcome to PureScript” materials…maybe take the “differences from Haskell” part of the language reference and a couple of the Elm recipes and the stuff that @bjornkihlberg says here about TypeScript and… that might already be quite a good resource and a nice complement to other ways of learning (cookbook, language reference, book etc)
This is why I found @marick’s book so helpful for starting out. It teaches PureScript from an assumed Elm background (which is what I had). So still FP, but the point is that it helps to leverage what new users already know.
I think it would be really valuable to have a comparison to other languages page in the official docs. Each language’s section would include:
Syntax comparison cheatsheet and examples (similar to your TS example).
An unopinionated summary of tradeoffs between the languages.
I have two major reservations about LYAH. Firstly, some of the jokes and examples it uses are very insensitive to certain groups of people. Secondly, I don’t think it’s actually very good as a learning resource - I personally used it when I was beginning Haskell, and I (and many other people in the Haskell community) found that I felt like I was getting it when I was reading it, but when I tried to actually apply what I’d learned, I found that I was completely unable to. I strongly agree with Chris Allen’s assessment of it:
The monkey-see monkey-do process is a warm-up, not an effective way to learn Haskell.
Do I recommend it? No. […] I am tired of doing clean-up duty on people confused by LYAH as are the other teachers in the IRC channel.
Yes, definitely noticed a lot of problematic sections in there. I figure we can strip those out.
And I agree about the “warm-up” element. Similar to just watching lectures, feeling good about your understanding of the material when you’re able to follow along passively, but then not being fully equipped to tackle any problems on your own. LYAH could use some exercises.
My other major concern is in fragmenting our efforts across multiple forms of documentation, rather than focusing on developing a really excellent core set.
The reasoning behind the LYAH port is that it seems fairly low-effort, and would be a nice way to reach folks who are already familiar with the original resource.
As a beginner myself that didn’t get too far into using PureScript in production, but am able to at least write a few programs for solving adventofcode I think what I’d do to get someone who has 0 experience with FP & PureScript is first cover the idea behind types & type constructors via the box analogy as Jordan does in his git-book-type of thing.
I’d say that the first few tutorials of this series https://github.com/adkelley/javascript-to-purescript might be the most beginner-friendly stuff we can find on the nets. Although it soon starts making assumptions of what the reader would understand in terms of FP so it only gets you so far. They also use the box analogy extensively.
Another things I’d say, as a beginner, in order to get a decent understanding of FP mechanics is through parsers. Writing a parser from scratch that is. I feel like this should be covered in depth as a practical first example since it’s the most natural. FP turns out it’s great at simplifying parsing.
This particular exercise: JSON Parser 100% From Scratch in Haskell (only 111 lines) which can be easily adapted to PureScript has helped me understand some of the stuff about monads and state that I would have otherwise had hard time with. I think it gradually builds up and even if you’re 100% new to all this stuff I’d be surprised if you didn’t take anything away from it. Of course, knowing the syntax at least to some extent helps a lot.
