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]
<mailto:[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
