Hi,
When dealing with fixed-point combinators I have always found
it useful to start by renaming variables to reflect their meaning
(here is an applicative-order combinator appropriate to Scheme,
the one you gave doesn't work for Scheme):
(define (Y fun) ; "fun" is a user function
((lambda (g) (g g)) ; "g" is a function
(lambda (f) ; "f" is a function
; "FF" function:
(lambda (data) ; "data" is input to "fun"
(fun (f f) data)))
))
Anyway, it works roughly as follows:
1. The "g" function is equal to the (lambda (f) ...), since that is
passed as an argument in Y body.
2. Then "f" is equal to "g", since there is a (g g) call.
3. So, the result of the (Y fun) call is a function which expects
"data" (call it "FF"). This is because (lambda (f) ...) is passed
as "g" which is then is applied to itself, resulting in the "FF"
expression, which is a function.
4. value of (f f) is the result of evaluating the (lambda (f) ...)
expression, which is once again a function expecting some more
"data" (this is "FF" again)
5. the function "fun" does one step of the recursion, given some
initial "data" and this value of (f f) aka "FF", resulting in:
6a. value (if no further recursive calls were made), or
6b. resulting in more invocations of the same "FF" (passed to it via
(f f)) expecting more "data", with appropriate next "data" supplied
inside "fun".
This way you can also see the problem with normal-order Y combinator
that you gave in Scheme:
((lambda (f) (fun (f f))) (lambda (f) (fun (f f))))
will continuously call this (lambda (f) ...) with itself as a parameter
without actually diving to "fun", because the (f f) parameter has be
evaluated before calling "fun".
If this only confuses you, a Google search on "The Why of Y" can help
(by Gabriel, Felleisen or Barzilay)...
Kind regards,
Pjotr Kourzanov
P.S. Thus the Y combinator is a complicated way of reflecting the
value of "f" back to itself (initially, via "g"), as long as needed.
The interesting thing is that all of this happens completely behind
the the back of "fun", inside the Y combinator. So (un)Icon
implementation might implement it the same way, using a trampoline to
ensure tail-recursive operation.
On Wed, 2011-12-21 at 12:03 -0800, David Gamey wrote:
> Bruce,
>
>
> Get well!
>
>
> You may find you end up being the expert on scheme to Unicon!
>
>
>
>
> Since you had some nested lambda's going on then I suspect once you
> crack that you may be able to solve Y. I've only been looking at it
> over coffee and in waiting rooms - not enough to get my head around
> the mechanics of it (below). I can follow it and almost see it but I
> have no feeling for what scheme is doing under the covers.
>
>
>
>
> (define (Y f)
> ((lambda (x) (x x))
> (lambda (x) (f (x x)))))
>
> (define factorial (Y almost-factorial))
>
>
> If you do I'd love to hear.
>
>
> David
>
>
> ______________________________________________________________
>
> From: Bruce & Breeanna Rennie <[email protected]>
> To: [email protected]
> Sent: Wednesday, December 21, 2011 1:18:37 PM
> Subject: Re: [Unicon-group] What is the idiomatic way to
> represent Lambda function in Icon/Unicon
>
> Thank you David,
>
> I have just downloaded the last Generator issue and will look
> at this later today. I much appreciate your direction and
> guidance on this matter. It looks like I'll have something to
> read while confined to my sick bed for today.
>
> regards
>
> Bruce Rennie
>
> On 22/12/11 01:47, David Gamey wrote:
> > Bruce,
> >
> >
> > The call in every c(simpleMap(tree)) is the activation of
> > co-expression c using the new(er) procedural syntax.
> >
> >
> > This may help http://rosettacode.org/wiki/Icon%
> > 2BUnicon/Intro#Co-expression_Flow
> >
> >
> > If you haven't already read it Steve's article in The
> > Generator v2n2 Fun with Co-expressions, part 2 explains
> > this. There's links from RC's Unicon page and the intro
> > above.
> >
> >
> >
> > Sorry, I don't have time for a longer explanation today.
> >
> >
> >
> >
> > Other RC tasks that use may provide examples
> > * http://rosettacode.org/wiki/Accumulator_factory
> > * http://rosettacode.org/wiki/Anonymous_recursion
> > * http://rosettacode.org/wiki/Closures/Variable_capture
> > * http://rosettacode.org/wiki/Function_composition
> > * and as I mentioned there is a Y-combinator page but
> > it hasn't been solved for Unicon
> >
> >
> >
> >
> > David
> >
> >
> >
> >
> >
> >
> >
> >
> > ____________________________________________________
> >
> > From: Bruce & Breeanna Rennie <[email protected]>
> > To: [email protected]
> > Sent: Wednesday, December 21, 2011 6:24:47 AM
> > Subject: Re: [Unicon-group] What is the idiomatic
> > way to represent Lambda function in Icon/Unicon
> >
> > Thanks to both Steve and David for your respective
> > pieces of information. I have been able to get a bit
> > further into solving my problem which is translating
> > the scheme interpreter for KERNEL (SINK) into
> > Unicon/Icon. The reason for the translation is that
> > SINK runs real slow.
> >
> > The next little problem, is finding a way to
> > generate lots of anonymous functions. I seem to
> > recall seeing something like that quite a few years
> > ago.
> >
> > The following scheme code gives the idea of what I
> > am translating. The following is an extract from
> > John Shutt's SINK file object.scm
> >
> > #; (define make-foo
> > #; (lambda (bar quux)
> > #; (let ((name (list #t)))
> > #; (lambda (message)
> > #; (case message
> > #; ((type) 'foo)
> > #; ((name) name)
> > #; ((bar) bar)
> > #; ((quux) quux))))))
> > #;
> > #; (define foo? (make-object-type-predicate
> > 'foo))
> > #;
> > #; Sufficient accessors should be provided that
> > clients never have to know that
> > #; encapsulated objects are dispatch procedures; for
> > example, if clients should
> > #; have the ability to access the 'bar and 'quux
> > attributes of a foo,
> > #;
> > #; (define get-foo-bar (lambda (x) (x 'bar)))
> > #; (define get-foo-quux (lambda (x) (x 'quux)))
> > #;
> >
> > #;
> > #; Determines whether all its arguments are objects.
> > #;
> > #(define object? procedure?)
> >
> > #;
> > #; Given some number of symbol arguments, constructs
> > a predicate that takes
> > #; an argument and determines whether it is an
> > object whose type is amongst
> > #; the given symbols.
> > #;
> > #(define make-object-type-predicate
> > # (lambda types
> > # (lambda (object)
> > # (and (object? object)
> > # (pair? (member (object 'type)
> > types))))))
> >
> > The make-object-type-predicate is used to generate
> > anonymous functions.
> >
> > I have just another look at what you have written
> > Steve as below.
> >
> > procedure applyTests(tree, env, context)
> > c := create repeat {
> > operand := (result@&source)[1] # allows
> function-style calls
> > result := operand(env, context) # in case
> result is needed
> > }
> > @c # advances evaluation CE to 'synchronization
> point', so next
> > # value passed in gets assigned to operand.
> > every c(simpleMap(tree)) # here, result is ignored
> > end
> >
> > Would you mind explaining what is happening here. I
> > think I have maybe completely missed what is going
> > on here. See if I have this right.
> >
> > result is a local variable with the initial value of
> > &null
> > result@&source simply returns control back to
> > applyTests at the line @c
> >
> > What I stuck at is (and I thought I understood but
> > sure now I don't) the line
> >
> > every c(simpleMap(tree))
> >
> > What is actually happening here and how does this
> > relate to the code in the co-expression
> >
> > operand := (result@&source)[1]
> > result := operand(env, context)
> >
> > I should be using Unicon much more but most of the
> > work I do these days is based on Microsoft Office
> > products as these are the tools that my clients run
> > and so it is VBA mostly.
> >
> > I think I need to get more stuff done in other
> > languages.
> >
> > Anyway back to the problem at hand. Would you mind
> > explaining in detail what is happening here,
> > please.
> >
> > Clinton, would a extra section in your book be able
> > to be written on these kinds of subjects?
> >
> > regards
> >
> > Bruce Rennie
> > getting slower as I age.
> >
> >
> >
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> > Write once. Port to many.
> > Get the SDK and tools to simplify cross-platform app
> > development. Create
> > new or port existing apps to sell to consumers
> > worldwide. Explore the
> > Intel AppUpSM program developer opportunity.
> > appdeveloper.intel.com/join
> > http://p.sf.net/sfu/intel-appdev
> > _______________________________________________
> > Unicon-group mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/unicon-group
> >
> >
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> > Write once. Port to many.
> > Get the SDK and tools to simplify cross-platform app development.
> Create
> > new or port existing apps to sell to consumers worldwide. Explore
> the
> > Intel AppUpSM program developer opportunity.
> appdeveloper.intel.com/join
> > http://p.sf.net/sfu/intel-appdev
> >
> >
> > _______________________________________________
> > Unicon-group mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/unicon-group
>
>
>
>
> ------------------------------------------------------------------------------
> Write once. Port to many.
> Get the SDK and tools to simplify cross-platform app
> development. Create
> new or port existing apps to sell to consumers worldwide.
> Explore the
> Intel AppUpSM program developer opportunity.
> appdeveloper.intel.com/join
> http://p.sf.net/sfu/intel-appdev
> _______________________________________________
> Unicon-group mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/unicon-group
>
>
>
> ------------------------------------------------------------------------------
> Write once. Port to many.
> Get the SDK and tools to simplify cross-platform app development. Create
> new or port existing apps to sell to consumers worldwide. Explore the
> Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
> http://p.sf.net/sfu/intel-appdev
> _______________________________________________ Unicon-group mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/unicon-group
------------------------------------------------------------------------------
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create
new or port existing apps to sell to consumers worldwide. Explore the
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu/intel-appdev
_______________________________________________
Unicon-group mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/unicon-group
