Scheme: Procedures that return another inner procedure | Hacker News Reader

Scheme: Procedures that return another inner procedure

stackoverflow.com

43 pointsluu13 comments

This is the "closure/object isomorphism", basically.

The outer function (cons) is a class constructor. It returns an object, which is a function of one argument, where the argument is equivalent to the name of a method. In this case, the methods are getters, so they evaluate to values. You could just as easily have stored more procedures in the object returned by the constructor.

In this case, numbers where chosen as method names and sugary procedures defined outside the object itself. You could have used symbols:

    (define (cons x y)
      (lambda (method)
        (cond ((eq? method 'car) x)
              ((eq? method 'cdr) y)
              (else (error "unknown method")))))

In which case what you have more closely resembles OO:

    # (define p (cons 1 2))
    # (p 'car)
    1
    # (p 'cdr)
    2

Nice. Or you can use the procedural representation. E.g. in Clojure:

    (defn pcons [x y] (fn [m] (m x y)))
    (defn pcar [z] (z (fn [p q] p)))
    (defn pcdr [z] (z (fn [p q] q)))

    (pcar (pcons 2 3)) ==> 2
    (pcdr (pcons 2 3)) ==> 3

I still look at this, and the whole LC encoded structures, with amazement. I love how things are mutually molded together and almost empty. Most of the LC felt that way, accumulation of lots of nothingness that achieve something.

How lazy of you :)

For people interested in `oop` in scheme, http://okmij.org/ftp/Scheme/oop-in-fp.txt

There's also this: http://www-inst.eecs.berkeley.edu/~cs61a/reader/belowline.pd...

(The "above the line" document mentioned is here: http://www-inst.eecs.berkeley.edu/~cs61a/reader/aboveline.pd...)

Not sure how much overlap the two have.

Great !

The way it is presented, object oriented programming languages sound like something different...as if when we lifted the covers on the code in which such languages are implemented, we would see homunculli operating the object mechanism instead of ordinary code. I remember marveling at the idea that objects are just dispatch and in one important sense no more clever than switching on a user keypress in some DOS .bat file menu.

That’s the point of an abstraction. What happens behind the curtain is (allegedly) not relevant to the mental model we form to do our work.

You can compile OO code into assembler. You can implement it with functions and closures. You can run it on a VM with special support for virtual dispatch.

In order to be an effective abstraction, you have to think of it as being different. I’d go so far as to say, if you look at OO and say to yourself, “this is just inside-out objects” and dismiss it as not brining anything to the table, you’re missing the point entirely.

Of course, you ought to realize that an object is an inside-out closure, and a closure is an inside-out object. But as an enlightened thinker, you can hold that idea in your head and simultaneously hold in your head the idea that they are different things.

[edit: I should bracket this with something about how when I am talking about OOP languages here, I was not thinking about Smalltalk]

What I was getting at is that Object Oriented Programming Languages are typically presented in "popular culture" as something discrete and concrete: that C++ is as discontinuous with Scheme as walruses are with penguins. And by this I'm not making a beeline for the Turning tarpit because we are talking about the same abstraction: dispatch.

I suppose that's why I haven't ever found object oriented programming fit quite right into the wrinkles in my cerebrum. I'm still trying force fitting the world into a model based on the computational idiom of dispatch...it's selecting an implementation mechanism as the first step. Object oriented programming feels to me like it is primarily an abstraction about computers not the world...and the simpler abstraction of dispatch works better for me because it is simply simpler.

It takes time to finally accept such abstractions. For the first ten years, I had to look under the hood to get a grasp of things, until you saw enough to finally accept staying in the domain, not caring about syntax.

Funny thinking that Lisp started as a blackboard experiment.

[1] unless you hit P vs NP territory.

Ah, this is like closures or decorators in python.

Those are closures (btw, did you mean generators instead of decorators?). Until nonlocal (https://www.python.org/dev/peps/pep-3104/), python closures were limited (http://stackoverflow.com/questions/141642/what-limitations-h...). Even though nonlocal solves the problems, the resulting scoping rules are messy: global, local, nonlocal, ...

Reply on news.ycombinator.com