public inbox for kawa@sourceware.org
 help / color / mirror / Atom feed
From: Jamison Hope <jhope@alum.mit.edu>
To: kawa@sourceware.org
Subject: Re: Using eval with environments and R7RS modules
Date: Wed, 2 Dec 2020 09:58:30 -0500	[thread overview]
Message-ID: <CA+ghDQ8JUj_GoeLJZG5R3US+a7F8Am4vZvzw0vbjyvDMq=zMSQ@mail.gmail.com> (raw)
In-Reply-To: <350b87e4-498f-8108-c2f5-f5397356b10f@oca.eu>

On Mon, Nov 30, 2020 at 1:09 PM Damien MATTEI <damien.mattei@oca.eu> wrote:

>
> strange that the SICP cover book put the couple EVAL / APPLY as
> important notion, APPLY seems more usefull,


FWIW, I would point out that SICP is *not* a book on how to program in
Scheme. It uses Scheme, yes, but much like the pseudo code in CLRS, it’s
just as an easy-to-understand syntax for presenting concepts about
programming. We did have to write and run some programs in 6.001 on actual
computers for homework, but most of the work was done on paper or a
chalkboard. (There were no computers in the room for the final exam.)

The pair of EVAL/APPLY presented the two stages of *Interpreting* a
Computer Program using the environment model: after parsing the Structure
(which for Lisp just means turning text with parentheses into a list of
atoms and lists — I don’t recall SICP mentioning vector literals, but it’s
been a while), the two steps to interpret the program — to decide what the
program’s result is — are to evaluate the car of the list to see what
function it represents, then evaluate each function argument, and then to
apply the function to its arguments (each of those EVAL steps might entail
recursively EVAL/APPLYing an inner function application). There’s a little
more to it to handle special forms like IF which don’t evaluate every
argument first, but that’s the essence of the model.

This was really a mental exercise, not a description of how a real physical
computer does or should work. The chapter on register machines and
compilation addresses the fact that in reality we don’t need to use EVAL to
look up each variable at runtime, because we can precompute where that
variable resides in the stack based on where it was defined (see the
section called “Lexical Addressing”).


>
>
> Damien
>
> -JH

-- 
Jamison Hope

  reply	other threads:[~2020-12-02 14:58 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-30  6:21 Duncan Mak
2020-11-30  6:35 ` Per Bothner
2020-11-30  8:12   ` Duncan Mak
2020-11-30 12:30     ` Per Bothner
2020-11-30 22:15       ` Duncan Mak
2020-11-30 10:13 ` Damien MATTEI
2020-11-30 12:21   ` Per Bothner
2020-11-30 18:09     ` Damien MATTEI
2020-12-02 14:58       ` Jamison Hope [this message]
2020-12-04  8:05         ` Damien MATTEI

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CA+ghDQ8JUj_GoeLJZG5R3US+a7F8Am4vZvzw0vbjyvDMq=zMSQ@mail.gmail.com' \
    --to=jhope@alum.mit.edu \
    --cc=kawa@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).