From: "Maciek Godek" <pstrychuj@gmail.com>
To: "Jon Wilson" <jsw@wilsonjc.us>
Cc: guile-user@gnu.org
Subject: Re: Me no understand scoping
Date: Wed, 30 Jul 2008 21:24:02 +0200 [thread overview]
Message-ID: <e2ceda030807301224j41cfe328k182c6620801516e6@mail.gmail.com> (raw)
In-Reply-To: <489074A9.1080508@wilsonjc.us>
>> as for eval, it will always be there (in RnRS)
>
> EVAL has not been in every report. R4RS did not specify EVAL, nor did R3RS,
> RRRS, RRS.
The fact that R5RS does only proves the fact that they should have :)
By the way I have a question (regarding not using eval).
I want to pass the contents of a list to a function that accepts the
so-called "rest" args.
(let ((l '(1 2 3 4 5)))
(let ((operation (append '(+) l)))
(primitive-eval operation)
)
)
How to achieve this effect without using eval?
(I've tried (+ . l) but it didn't work out)
>> besides I don't imagine not messing with lexical
>> environments :) The bad thing is that scopes aren't
>> explicitly definable and the report doesn't say
>> much about their properties. I don't know how
>> about practical performance, but I'd find it best
>> if they were implemented as (implicit) hash tables
>> that could be bound to variables and passed as
>> arguments. I think that they could perform
>> equally good as fixed arrays for memoized
>> procedures.
>
> The view of the scheme community as a whole is that first class lexical
> environments are irreconcilable with the need to compile (optimize) code.
Certainly there's a faction that thinks differently :]
> In many cases, once you have done some variety of compilation, a lot of the
> lexical environments you think you ought to have will have been optimized
> away; conversely, preserving these environments will prevent entire classes
> of compilation.
Unless some limitations are to be imposed on compiled closures
(and some control over optimization is given to the programmer)
I see no problem with that.
> I am of the suspicion that in most cases, the environment would never be
> reified, the compiler could prove this, and optimization could proceed as
> desired. However, I would still agree with Clinton that you should avoid
> messing with environments, first class or otherwise, whenever possible.
> When you must, you should quarantine it: use it in a very limited part of
> your code, where you wrap it in a more mundane abstraction, then use that
> abstraction elsewhere. CALL/CC should be treated the same way usually.
Yeah, I always write additional layers so the code corresponds to the
way I think. (Everybody does, don't they?)
> Broadening the topic a bit, it seems that first class envs and macros (and
> maybe not macros!) are all that would be needed to define a module system in
> scheme, rather than building it into the interpreter. Then the module
> system could be put in a file which any r5rs+envs (or whatever standard you
> like) scheme could LOAD (most likely implicitly at startup) without
> modification to the interpreter itself. It might even be the case that
> DEFMACROs and reified environments would be sufficient to make low-level
> hygienic macros a library too (but I'm no macrologist, for sure). You would
> still have to deal with the compilation issues, but as I said, my gut
> feeling is that these are solvable.
Such a pretty vision you have :)
("and no religion too..." :P)
The thing is that this would really make *everything* simpler.
(or maybe it's just another collective hallucination)
next prev parent reply other threads:[~2008-07-30 19:24 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-29 21:18 Me no understand scoping Maciek Godek
2008-07-30 3:24 ` Clinton Ebadi
2008-07-30 8:42 ` Maciek Godek
2008-07-30 14:03 ` Jon Wilson
2008-07-30 15:04 ` Klaus Schilling
2008-07-30 19:24 ` Maciek Godek [this message]
2008-07-31 7:20 ` Neil Jerram
2008-07-31 19:21 ` Maciek Godek
2008-07-31 21:37 ` Neil Jerram
2008-07-31 23:07 ` Maciek Godek
2008-08-02 17:43 ` Neil Jerram
2008-08-02 21:36 ` Maciek Godek
2008-08-08 20:54 ` Neil Jerram
2008-08-10 21:49 ` Maciek Godek
2008-08-09 11:05 ` Andy Wingo
2008-08-10 22:30 ` Maciek Godek
2008-09-11 14:56 ` JonWilson
2008-07-31 23:48 ` Clinton Ebadi
2008-08-01 22:00 ` Maciek Godek
2008-08-02 5:13 ` Jon Wilson
2008-08-02 21:35 ` Maciek Godek
[not found] <cmu-lmtpd-29005-1217434291-0@mail-imap1.uio.no>
2008-07-30 16:18 ` Kjetil S. Matheussen
2008-07-30 19:03 ` Clinton Ebadi
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
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e2ceda030807301224j41cfe328k182c6620801516e6@mail.gmail.com \
--to=pstrychuj@gmail.com \
--cc=guile-user@gnu.org \
--cc=jsw@wilsonjc.us \
/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).