8functional-programming_1115 - CSci 5106: Programming...

Info iconThis preview shows pages 1–3. Sign up to view the full content.

View Full Document Right Arrow Icon

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
This is the end of the preview. Sign up to access the rest of the document.

Unformatted text preview: CSci 5106: Programming Languages Functional Programming and Standard ML Gopalan Nadathur Department of Computer Science and Engineering University of Minnesota Lectures in Fall 2010 Gopalan Nadathur Functional Programming Functional Programming A paradigm of programming in which computation consists mainly of expression evaluation Power arises from treating functions almost like any other object They can be passed as arguments (define (compose f g) (lambda (x) (f (g x))) They can be returned as results (define succ (x) (+ x 1)) (compose succ succ) They can be embedded in data (cons (compose succ succ) (cons succ nil)) The one exception: we typically cannot look inside functions For example, we cannot carry out comparisons like (compose f g) == (compose (compose f g) (lambda (x) x)) Gopalan Nadathur Functional Programming Tenets of Functional Programming Central interest is in values and not in how they are stored Focus is on the conceptual view of data, not on representation or layout For example, consider lists in ML or Scheme versus in C Storage allocation and deallocation is handled implicitly For example, consider append and garbage collection Computation is (largely) side-effect free Value of an expression depends largely on those of the subparts and not on how they are calculated Actually true for lazy functional programming , e.g., Haskell Order could affect efficiency and termination, though Assignment, input and output, etc, are intended to be used sparingly Gopalan Nadathur Functional Programming Categories of Functional Programming Languages Lazy versus Eager Languages Lazy Evaluation: Evaluate arguments only as needed by the operator (i.e., demand driven) Eager Evaluation: Evaluate arguments and operator first and only then try to apply the operator Eager evaluation may be more efficiently implementable Lazy evaluation admits intriguing possibilities, e.g., infinite objects Have to work to get side-effects into lazy languages (monads) Even eager languages need laziness sometimes, e.g. in conditionals, to be practically useful Eager Functional Languages: Lisp, Scheme, Standard ML Lazy Functional Languages: Miranda, Daisy, Haskell Gopalan Nadathur Functional Programming Categories of Functional Programming Languages Typed versus Untyped Languages In the typed version, the set of values are classified as belonging to specific subcategories For example + int -> int -> int fact int -> int 2,3 int In the untyped version, all values are treated uniformly; thus (+ +) and (2 2) are both syntactically acceptable Problems could arise when trying to interpret + as an input to addition and 2 as an operator Question: Is this dynamically typed or untyped?...
View Full Document

This document was uploaded on 05/06/2011.

Page1 / 23

8functional-programming_1115 - CSci 5106: Programming...

This preview shows document pages 1 - 3. Sign up to view the full document.

View Full Document Right Arrow Icon
Ask a homework question - tutors are online