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

Reply via email to