Fwd: [plt-scheme] Newbie Lambda( ) (???????????)

From: e (eviertel at gmail.com)
Date: Sat Feb 14 23:10:42 EST 2009

I don't think I sent this to the group last time.  Something odd still about
how I interact with this group vs. the other ones I'm in:

ok, I am new, too,  to fp, so, perhaps partially to help me learn ... I was
somewhat confused by the stop example, at first, also.

I initially thought that once you defined "stop" one time, you were set
forever.  I was sort of assuming symmetry between "server" and "stop". . . .
like, after the definition, you could just call (stop) after every call to
(server 8081).  But the example was adamant that we had somehow "fixed" the
problem of not shutting down the listener.  So I started thinking it
through, like, "what I really need is a handle to something, like the
thread  . ..  yeah the ACTUAL one that the listener is using . . . .so I can
kill it".  And that was it.  I understood enough to know that what's needed
is to *redefine stop every time you start the server*.  That's the part I
didn't grok right away.  You're not making a reusable function called
"(stop)" the way you are making a reusable function "(server)".

Not only CAN you return a function, the REASON you are in this case is so
that its execution will be tied (bound) to the thread that was started.  I
am thinking this is an example of a "closure".

I guess in OO, you'd make a server "instance", and it would have a "stop"
command . . .. or you could "delete" it (in C++), which would call the
"destructor" . . . or in Java, there's some what of an opportunity in
"finalize()", but not a reliable one.  In Python, I'm thinking you'd have a
"stop", and it'd be obvious that construction and "stopping" aren't
symmetric operations.

Now that I've made this comparison, it seems like the argument you have for
fp reduces from "you can't do this in OO" to, "you need more boilerplate and
fanfare to do it in OO" (possibly a whole file, possibly two -- one for the
header and one for the implementation, RAII semantics on the constructor,

Then Macro said:

Yes, you are on the right track. It would be a lot more verbose in OO.
There are some things that are done better by an OO language (e.g.
encapsulation and polymorphic dispatch). Others, however, are
incredibly hard to do (and should not as demonstrated by FP).




On Fri, Feb 13, 2009 at 5:03 PM, Marco Morazan <morazanm at gmail.com> wrote:

> On Fri, Feb 13, 2009 at 1:35 PM, Jesus Boadas <jboadas at gmail.com> wrote:
> > Thanks I understand now, this is new to me. My usual functions only
> return
> > values, never could imagine that a function could return a function, I
> was
> > doing some research and this is called higher order functions or I am in
> a
> > mistake?.
> >
> No, you are not. You are quite right. It is quite elegant, no? :-)
> Consider, now, a function, f, that returns a function as its value
> after being applied to a set of arguments. A nice way to think of such
> a function is as specialized-function generator. For example, consider
> the problem of creating functions (i.e. what you do when you write
> functions) that return a list with the results of adding a constant to
> every element of a list of numbers. You would like to write a function
> that takes as input a number (i.e. the constant to add) and that
> returns a function that takes as input a list of numbers and that
> returns a list by adding the given constant to every element of the
> list. The code for this could look something like this:
> ; make-list-adder: number --> (list-of-numbers --> list-of-numbers)
> (define (make-list-adder n)
>    ; add: number --> number
>    (define (add m) (+ n m))
>    ; add-n-to-list: list-of-numbers --> list-of-numbers
>    (define (add-n-to-list lon) (map add lon))
>  add-n-to-list)
> Every time make-list-adder is applied to an argument it returns a
> function for which n is fixed. We can now, for example, define
> functions to add 1 and to add 5 to every element of a list of numbers
> without having to explicitly write code (in the conventional sense):
> (define add-1-to-list (make-list-adder 1))
> (define add-5-to-list (make-list-adder 5))
> The above definitions should illustrate that we have not written the
> code for neither add-1-to-list nor add-5-to-list in the conventional
> sense, but yet we have functions we can use!
> (add-1-to-list (list 1 2 3)) = (list 2 3 4)
> (add-5-to-list (list 1 2 3)) = (list 6 7 8)
> By writing one abstract function, we have the power to define a whole
> class of functions. I hope this gives you an appetite to learn more
> about HOFs.
> --
> Cheers,
> Marco
> _________________________________________________
>  For list-related administrative tasks:
>  http://list.cs.brown.edu/mailman/listinfo/plt-scheme
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20090214/8db5bd12/attachment.html>

Posted on the users mailing list.