public inbox for kawa@sourceware.org
 help / color / mirror / Atom feed
From: Damien MATTEI <damien.mattei@oca.eu>
To: kawa@sourceware.org
Subject: Re: Using eval with environments and R7RS modules
Date: Mon, 30 Nov 2020 19:09:16 +0100	[thread overview]
Message-ID: <350b87e4-498f-8108-c2f5-f5397356b10f@oca.eu> (raw)
In-Reply-To: <60e9b887-73ef-76f8-87e1-a8158802beef@bothner.com>

yes Per i almost never use EVAL, i finally find a better solution than 
with EVAL in the macro i was writting.

I needed to EVAL a quoted argument of a macro but ,it was finally useless.


Le 30/11/2020 à 13:21, Per Bothner a écrit :
> On 11/30/20 2:13 AM, Damien MATTEI wrote:
>> (define (foo L)
>>
>>     (eval L (interaction-environment))
>>
>> and i got an error like UNBOUND VARIABLE L
>>
>> but this not only in Kawa,it is in Scheme, i was in a R5RS ,
>
> The eval functon is really not compatible with lexical scoping, at least
> not unless you use a different evaluation strategy which make Scheme
> run much slower and use more memory. And that would be all the time,
> not just when eval is used (possibly unless you made eval a special
> syntax the compiler could recognize, rather than a procedure).
>
> Scheme from the very beginning has focused on lexical scoping and
> being able to compile it to efficient code:
>
> https://en.wikisource.org/wiki/Lambda_Papers
>
>> if there is a way to know the current bindings from EVAL i will be happy
>
> Dynamic bindings, yes, but lexical bindings, no.  And that won't change.
>
>> to know it, because without this , i do not see any use for EVAL ,
>
> I've many times said there is very little use for eval, and that too many
> people overuse it.

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

i will try to find examples in the french edition of this book i have

>
> If you think you have a good use for eval, you're probably wrong.
for now no, but i just discover i have to rewrite code that only works 
in toplevel (Gasp...)
>
>> having only the toplevel bindings is not enought for development.
>
> If you mean that eval is not very useful for debugging, that is true.


Damien


  reply	other threads:[~2020-11-30 18:09 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 [this message]
2020-12-02 14:58       ` Jamison Hope
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=350b87e4-498f-8108-c2f5-f5397356b10f@oca.eu \
    --to=damien.mattei@oca.eu \
    --cc=Damien.Mattei@unice.fr \
    --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).