20-CS-4003-001 Organization of Programming Languages Fall 2017
Scheme Properties

Lambda calculus, Type theory, Formal semantics, Program analysis

    Prev     Next     All lectures

Scheme Properties

Not Imperative (w/ exceptions)
    no side effects (except when set! and such are used)
uses lambda - students don't like it
loss of speed compared to imperative paradigm
students don't like nested levels of parens
Object-oriented via lambda
    see closures below
    speed to a (semi) working product is even better than for Java
    needed language reference is one sheet of paper - Java requires reams
    procedures (expressions) tend to be incredibly short
    not so good:
    to be determined
Polymorphism is not really developed
    depends on point of view - OK if dynamic typing is preferred
    analyzing code for security problems is harder
Dynamically typed
    improved expressibility and flexibility over Java - examples to follow
    not so good:
    many type errors are not found at compile time
    more type checking is done at runtime hindering performance
Type safe
   the absence of erroneous or undesirable behavior caused by a
   discrepancy between differing data types
    not so bad:
    type safety is enforced at runtime
Functions are first class objects
  1. can be assigned a value
  2. can be composed with other entities in composites ((lambda (x) ((lambda (y) (+ x y)) 2)) 3)
  3. can be passed as an argument to a function
  4. can be returned as a function result
Closures support impressive applications
   a function and environment containing free variables which can be carried as an object
   to other points of code where the function can be executed while referencing the free
   and bound variables of the environment
    continuation passing style - tail recursion
    novel forms of control without side-effects are possible
    Y combinator - no function, even recursive, needs to be named
    many students complain about too many lambdas and parens
    many students can't appreciate how closures hide state
    many students don't realize that closures are not anonymous functions
No real concept of pointers
   functions have values when invoked
    pointers are not part of a specification and can cause trouble
    nothing really
Has garbage collection
    space is reclaimed
    wasted, unreferenced, unused space is reduced or eliminated
    garbage collection may take a significant amount of time
Memory safe
    memory is not leaked, no buffer overflow, etc.
    stack overflow is possible
Collateral computation via heap
   tree of stacks
    extends exceptions in a semantically logical way
    supports call-with-current-continuation
    no deadlock problem
    no worry about synchronization
    nothing really
Lexically scoped
   the scope of a declaration is the region of the program where that variable can be referenced
    scope is known at compile time and can be completely determined from the text of the code.
    application programmer understands scope as it is made clear in the syntax of the language through ( and ), for example.
    not so bad:
    loss of flexibility - e.g. set up display variable at some particular point of execution, then reference it from anywhere later
    understood semantics - chance of verifying or validating correctness is increased because less about what is happening inside the function is known to or accessible by the caller.
    but only references to objects are passed instead of the objects
    not too bad:
    loss of flexibility - e.g. call-by-name, value-result, etc. are not available but this can be worked around.
Applicative order evaluation of parameters, left to right
   reduces terms within a function body as much as possible before
   the function is applied
Strict evaluation of parameters
   all parameters are evaluated before entering body