On Feb 11, 2014, at 10:06 AM, Matthew Johnson wrote:
> So in terms of my example:
>
> We have the general form: ( (lambda (x) e) V) ~ e with all [free] x
> replaced by V
>
> And for V <-- 2 :: ( (lambda (x) (* x y) 2) ~ (* 2 y) ?
>
> But for V <-- z^2 :: error and NOT ~ (* (* z z) y) ?
Not
So in terms of my example:
We have the general form: ( (lambda (x) e) V) ~ e with all [free] x
replaced by V
And for V <-- 2 :: ( (lambda (x) (* x y) 2) ~ (* 2 y) ?
But for V <-- z^2 :: error and NOT ~ (* (* z z) y) ?
Thanks
On 11/02/2014, at 3:59 PM, Matthias Felleisen wrote:
>
>
> Ouch,
Ouch, I forgot to explain V. NO, you canNOT replace x with arbitrary
expressions. You may use ONLY VALUES (V for Value). In this context a value is
one of: #t/#f, number, or a lambda expression. -- Matthias
On Feb 11, 2014, at 9:50 AM, Matthew Johnson wrote:
> The general form: ( (lambda
On Feb 11, 2014, at 12:48 AM, Matthew Johnson wrote:
> I am still a little unclear. Is this a logical result, or a result of the
> evaluator's rules? Or are they the same thing?
They are the same thing. To calculate with the Racket that you see in the
book/derivation, use this rule:
(
I can answer your last question: this operation (converting to CSP) is
almost never done manually. Many compilers/interpreters do this
operation before compiling/interpreting, including IIRC Racket; note
that by converting to CSP you eliminate non-tail recursion altogether
and replace it by an ad-h
On Tue, Feb 11, 2014 at 08:24:46AM +0100, Matthew Johnson wrote:
> Thanks, i think i understand that (lambda (e) (e x)) is a function,
> and that evaluating it produces a new function (the one we use in the
> recursive call - let's call it rf1).
>
> Is your meaning that rf1 protects the self-repli
Thanks, i think i understand that (lambda (e) (e x)) is a function,
and that evaluating it produces a new function (the one we use in the
recursive call - let's call it rf1).
Is your meaning that rf1 protects the self-replicator embedded in the
'else' clause from triggering, and so protects us fro
Thanks Matthias,
I am still a little unclear. Is this a logical result, or a result of the
evaluator's rules? Or are they the same thing?
It wasn't until i followed the logic of (mk-length mk-length) outside the
function that i saw it would replicate on and on - which i guess is what we
want so
On Mon, Feb 10, 2014 at 09:52:18PM +, Matthew Johnson wrote:
> Thank-you all for your help with my Y-combinator question.
>
> I've now got myself a copy of *The Little Schemer*, and think that i'm
> getting there.
>
> Some googling on the lambda calculus and fixed point combinators introduced
On Feb 10, 2014, at 4:52 PM, Matthew Johnson wrote:
> Why does (lambda (x) (e x)) make it evaluate once and stop? I mean how come
> when the evaluator gets to the call it doesn't get stuck in a loop?
This explicit function gets "copied" over and over again during function calls
(beta-value r
Thank-you all for your help with my Y-combinator question.
I've now got myself a copy of *The Little Schemer*, and think that i'm
getting there.
Some googling on the lambda calculus and fixed point combinators introduced
me the formalism:
((lambda (x) (x x)) (lambda (x) (x x)))
The general sett
For me, I didn't fully appreciate the Y combinator until I had had an
opportunity to play with and explore other combinators.
The book that made this fun for me was "To Mock a Mockingbird", a puzzle
book by Raymond Smullyan.
Chapters 9 and 10 give you all the building blocks you need to appreciat
We need more animations for this kind of stuff:
http://yinwang0.wordpress.com/2012/04/09/reinvent-y
-- Yin
On Thu, Feb 6, 2014 at 7:24 AM, Matthew Johnson wrote:
> Hi scheme experts,
>
> My question is really a plea for someone to fill in the gaps in a
> derivation of the Y combinator.
>
Two hours ago, Matthias Felleisen wrote:
>
> 2. when you have an expression e and you know it will evaluate to a
Missing at this point: "unary" (which leads to some nice homework to
understand it better).
>function if the evaluation terminates but it may not terminate,
>you can write (la
On Feb 6, 2014, at 10:21 AM, Matthias Felleisen wrote:
>
> On Feb 6, 2014, at 1:05 PM, Prabhakar Ragde wrote:
>
>> Matthew Johnson wrote:
>>
>>> My question is really a plea for someone to fill in the gaps in a
>>> derivation of the Y combinator.
>>
>> This is the source I use as a basis fo
On Feb 6, 2014, at 1:05 PM, Prabhakar Ragde wrote:
> Matthew Johnson wrote:
>
>> My question is really a plea for someone to fill in the gaps in a
>> derivation of the Y combinator.
>
> This is the source I use as a basis for my classroom presentations, with a
> few more details thrown in.
>
Matthew, you may wish to read the corresponding chapter in the Little
Schemer/Lisper. It is a available as a sample chapter from my web page. Or go
to a local library and get the book.
Two hints:
1. a lambda-bound name is arbitrary. Just because we use 'length' does not mean
it has anything
After reading the paper, I see that the missing ingredient in our
compiler is a data-flow analysis along the lines of 0-CFA. Others
(i.e., not me) are working on integrating such analyses and
optimizations into Racket, so I think that it will be possible
eventually.
At Tue, 29 Jun 2010 02:21:00 +0
If I understand you correctly, it is possible to see such an optimization in
Racket? It would be awesome to use this style to control the loops.
28.06.10, 23:47, "Matthias Felleisen" :
>
> I pointed out Jinx's paper to Matthew last week.
>
> Not surprisingly, reality and theory never match
I pointed out Jinx's paper to Matthew last week.
Not surprisingly, reality and theory never match with the MIT Scheme
compiler.
On Jun 28, 2010, at 3:04 PM, Joe Marshall wrote:
On Fri, Jun 25, 2010 at 11:50 AM, Matthew Flatt
wrote:
Compilers can't easily see through a Y combinator, an
On Fri, Jun 25, 2010 at 11:50 AM, Matthew Flatt wrote:
>
> Compilers can't easily see through a Y combinator, and a factor of 8 or
> so difference is probably typical for Lisp compilers. (I tried Ikarus
> and Gambit to double check, and performance was about the same as with
> Racket.)
See
@INPRO
Matthias Felleisen
writes:
> CODE:
>
> #lang racket
>
> (define-syntax U
> (syntax-rules ()
> [(_ f) (f f)]))
>
> (define-syntax define/comb
> (syntax-rules ()
> [(_ comb name (arg1 arg2) body)
> (define name
>(comb (λ (name) (λ (arg1 arg2) body]))
>
> (define (Z
This version misses an explicit combinator passing. Z can be replaced by I,
Z-memoize, Z-verbose or any other, this is the point.
25.06.10, 22:58, "Ryan Culpepper" :
> On 06/25/2010 12:59 PM, Groshev Dmitry wrote:
> > Is there any way to avoid this overhead? I'm really interested in
> > combin
On 06/25/2010 12:59 PM, Groshev Dmitry wrote:
> Is there any way to avoid this overhead? I'm really interested in
> combinator style, but if it makes programs 8 times slower, it is
> useless. Maybe some compiler/macro optimizations is possible?
You might find this version interesting:
(define-syn
Is there any way to avoid this overhead? I'm really interested in combinator
style, but if it makes programs 8 times slower, it is useless. Maybe some
compiler/macro optimizations is possible?
25.06.10, 22:50, "Matthew Flatt" :
> If you're interested in specially the overhead of combinator styl
If you're interested in specially the overhead of combinator style,
then your example still understates the overhead compared to relatively
cheap operations.
In addition to Matthias's change to get rid of `apply', I've revised
your program (see below) to replace `first' and `rest' with `car' and
`
I think you're comparing apples and oranges here.
The use of _apply_ should make things a lost slower
for comb-sum than for sum. Also, you should collect
garbage before you run timed microbenchmarks. Otherwise
you might have bad interactions. With that done, I
get the following results:
> [:~/D
I've mistyped. In fact things are even worse.
#lang racket
(define-syntax U
(syntax-rules ()
[(_ f) (f f)]))
(define-syntax define/comb
(syntax-rules ()
[(_ comb name (arg . args) f)
(define name
(comb (λ (name) (λ (arg . args) f]))
(define (Z f)
(U (λ (g) (λ x
28 matches
Mail list logo
