Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

15-150: Principles of Functional Programming

brandonspark.github.io

Post reply on HN
Print view View original

141–146 of 146 posts

Re: 15-150: Principles of Functional Programming

#141

Post by weatherlight »

SomeRndName11 wrote: post #140
weatherlight wrote: post #139

Earlier quoted context omitted.

I did Programming Languages, Part A, (to learn FP semantics) many years ago. It doesn't show I never coded anything in SML, it shows I made a mistake :/ .I no longer have Standard ML on my machine. I thought having the `let` keyword encompass `fun` and `val.` was needlessly confusing. It's not concise. if `let` can mean so many things why not just do what Haskell did. Again.. it not "so much more verbose." which was…

No SML is more verbose, is pretty obvious. A simple "for" in ocaml could save lots boilerplate doing trivial recurison.

Functional programmers tend to use recursion instead of explicit loops with implicit state, and it's wise to regard for loops with suspicion since it can't return anything.

Standard ML as the language of instruction is a vehicle for teaching FP semantics, not imperative ones.

Also, Tower of Hanoi is a classic problem that's well suited for recursion.

Re: 15-150: Principles of Functional Programming

#142

Post by weatherlight »

__rito__ wrote: post #125
weatherlight wrote: post #73

Earlier quoted context omitted.

because SML is awesome, isn't going to change and is simple. you can learn the syntax in an afternoon, and really focus on learning FP semantics.

Albeit little, installing SML still requires some anount of gymnastics, google searching, and copying stuff from SO, GH Gists, etc. Yes, I agree broadly with the line of thinking that says- if you are learning FP, you must be willing to do these, but a beginner might be disheartened and turned away- especially as someone learning alone.

totally fair!

Re: 15-150: Principles of Functional Programming

#143

Post by kccqzy »

imslavko wrote: post #122
kccqzy wrote: post #109

Earlier quoted context omitted.

Oh definitely go deep into monads. If you use the ST monad to do mutations, some people think Haskell provides nicer syntax to do imperative programming than traditional imperative languages like C. But of course such nicer syntax only comes from understanding and using important abstractions like monads, foldable, or traversable. Then there are niceties like automatic SoA/AoS transformation using type families.

I don't think I have heard of the automatic AoS/AoS before, do you have good links to study more?

You can read the documentation for the vector package. (This is an extremely common package since it is a dependency for the JSON library aeson.)

Check out https://hackage.haskell.org/package/vector-0.13.1.0/docs/Dat...

Now if you understand the type family GHC extension, all this will be easily understood. If not, basically the idea is that you can automatically transform Array of Structs into Structs of Array by defining that transformation using a data family instance that you write yourself. For common types like tuples, the library already defined polymorphic instances for you.

Of course this transformation isn't always desirable and you don't have to use this. If your code isn't performance sensitive I wouldn't even bother with unboxed vectors; I'd just use regular vectors.

Re: 15-150: Principles of Functional Programming

#144

Post by ElectricalUnion »

squillion wrote: post #83
ElectricalUnion wrote: post #53

Earlier quoted context omitted.

From my limited knowledge of FP languages it is expected that pure code in fact doesn't evaluate anything until a monad forces it to evaluate. You would then need a monad to evaluate the things you're attempting to log. And at that point you have a monad, so you can log as usual?

It's not about monads, it's about effectful code, which is represented by special types (e.g. IO in Haskell, Eff in PureScript). Effectful code can call pure code, but not vice-versa. Since a program will have to do something , the main function is always effectful, i.e. it returns an effectful special type. So you're right that pure code isn't evaluated until some effectful code is ultimately returned by the main fu…

To me the issue is even simpler, not even about effectful code or monads, it's about the "issues" of lazy evaluation.

It doesn't really matter if you made a horrible uncomputable mistake deep inside a pure function, if you either discard or never use that mistake you would never notice it happened.

For example, nixpkgs (in nixlang) for sure isn't "strict pure FP" - you can do effects whenever you want - but will often have uncomputable evaluations in it. And you will only notice they're uncomputable evaluations when you try to use them. There's even a warning left for future wanderers for that:

    ### Evaluating the entire Nixpkgs naively will fail, make failure fast
    AAAAAASomeThingsFailToEvaluate = throw ''
      Please be informed that this pseudo-package is not the only part of
      Nixpkgs that fails to evaluate. You should not evaluate entire Nixpkgs
      without some special measures to handle failing packages, like those taken
      by Hydra.
    '';
I see that I formulated my thesis badly, conflating strict evaluation with monads, when as you pointed out they're not strictly related.

Re: 15-150: Principles of Functional Programming

#145

Post by SomeRndName11 »

weatherlight wrote: post #141
SomeRndName11 wrote: post #140

Earlier quoted context omitted.

No SML is more verbose, is pretty obvious. A simple "for" in ocaml could save lots boilerplate doing trivial recurison.

Functional programmers tend to use recursion instead of explicit loops with implicit state, and it's wise to regard for loops with suspicion since it can't return anything. Standard ML as the language of instruction is a vehicle for teaching FP semantics, not imperative ones. Also, Tower of Hanoi is a classic problem that's well suited for recursion.

You do not need to school me about why "for" is not pure functional - as soon as you understand that it is syntactic sugar, you are fine; IO is also impure, so if you insisting in purity then the only option is Haskell.

If you want to be pedantic, in functional programming there is no such a thing as "return value", as there is no such a thing as statement, only expressions. And expressions always _have_ values, they do not _return_ them.

I agree that SML is better for teaching than OCaml no doubt about it.

I mean, it is pointless to continue this conversation; you did not use SML for a long time - I did use it last time last year, and I can attest, it is extremely impractical compared to any other FP language today.

Post reply on HN