150 was one of my favorite courses at CMU; each homework really made me feel like I unlocked a new level of reasoning with code.
Do you if any of the course material is available online or as a MOOC?
15-150: Principles of Functional Programming
111–120 of 146 posts
Re: 15-150: Principles of Functional Programming
#112Re: 15-150: Principles of Functional Programming
#113Earlier quoted context omitted.
He is probably talking about namespaces. In common lisp, for example, (a a) calls a function 'a' on a variable 'a'. Lisp knows this because the first thing that comes after the left paren is a function
more importantly there are functions (using scheme as an example) like set! and set-cdr! that mutate existing values and totally break referential transparency. this isn't just user facing - for example let* kind of depends on creating bindings up front so they work across clauses, and then mutating them afterwards
Re: 15-150: Principles of Functional Programming
#114Earlier quoted context omitted.
Unfortunately, it does not. These lectures are "mine", in the sense that I developed all of them myself, but the homeworks and lab exercises are the combined efforts of generations of TAs and instructors from the past. It wouldn't be right for me to give them away. (they are also reused from time to time, so there are academic integrity concerns with that also)
(but I have thought of developing my own exercises independently to go with the lectures, to post on my website. This is generally a lot of work, though, so this might take some time, depending on how much people would benefit from it.)
Re: 15-150: Principles of Functional Programming
#115Earlier quoted context omitted.
more importantly there are functions (using scheme as an example) like set! and set-cdr! that mutate existing values and totally break referential transparency. this isn't just user facing - for example let* kind of depends on creating bindings up front so they work across clauses, and then mutating them afterwards
Why does `let*` need to have mutation? It can be nested `let`s.
Re: 15-150: Principles of Functional Programming
#116Earlier quoted context omitted.
(but I have thought of developing my own exercises independently to go with the lectures, to post on my website. This is generally a lot of work, though, so this might take some time, depending on how much people would benefit from it.)
Could be a classic kickstarter campaign style thing.
Re: 15-150: Principles of Functional Programming
#117Earlier quoted context omitted.
i think someone with a good grounding in sml could get proficient ocaml or f# in under a month. sml is absolutely the right language to teach a course like this in.
I agree with your first sentence, but the second one surprises me. If the practical language and the impractical one are that similar, why pick the impractical one?
http://adam.chlipala.net/mlcomp/ is a very good overview of the differences between sml and ocaml, which lets you see some of the tradeoffs each language has made.
Re: 15-150: Principles of Functional Programming
#118Earlier quoted context omitted.
Why does `let*` need to have mutation? It can be nested `let`s.
let* permits expressions on the right refer to arbitrary other symbols bound by the let*. in particular it allows for construction of recursive lambdas that may not be linearlizable.
In what language? I just checked Elisp, SBCL, and Guile, and they all error out if you refer to a variable not previously defined by a left-to-right traversal of the varlist:
(let* ((a (+ b 1)) (b 1)) a)
Edit: This doesn't work either: (let* ((a (lambda () (+ b 1))) (b 1)) (funcall a)) ; (funcall a) -> (a) for SchemesRe: 15-150: Principles of Functional Programming
#119Re: 15-150: Principles of Functional Programming
#120150 was one of my favorite courses at CMU; each homework really made me feel like I unlocked a new level of reasoning with code.
That's how I felt when I discovered FP after more than two decades writing procedural and OO code. It felt like I'd found a secret room where all the reasoning was kept.