difference between using eval from the interactive prompt and from a file?

[Per Bothner]

On 11/11/2011 11:21 AM, Helmut Eller wrote:
> * Per Bothner [2011-11-11 17:55] writes:
>
>> On 11/11/2011 02:02 AM, Helmut Eller wrote:
>>> R7RS section 5.1 Programs:
>>>
>>>    Expressions occurring at the top level of a program are
>>>    interpreted imperatively; they are executed in order when
>>>    the program is invoked or loaded, and typically perform
>>>    some kind of initialization.
>>>
>>> So I think this is one more case where Kawa is not standard conform.
>>
>> Ah, but when you say "kawa evaltest.scm" evaltest.scm is treated as a
>> module, not a program.  If you want evaltest.scm to be treated as a
>> R7RS "program" use the -f flag.  (Of course most of the time it
>> doesn't matter - in Kawa certain modules are often also programs,
>> or at least behave the same way when loaded.)
>>
>> So this is not an example of Kawa non-conformance.
>
> (with-language-lawyer-hat-on
>
> R7RS 5.5.1. Module Syntax (page 24):
>
>    The top-level forms in a module are executed in the order in
>    which they occur when the module is loaded.
>
> Seems to suggest that programs and modules should do the same.

Top-level forms in a (Kawa) module *are* executed in the order in
which they occur when the module is loaded.

The issue is
(a) while bindings are exported; and
(b) *how* are they exported.
In a (R7RS) module exported bindings are only visible when
imported into another module.  I haven't found a clear statement
in R7RS about how one can import a module into the top-level
environment.  (Either I haven't read it carefully enough, or
that is arguably a flaw in R7RS.  I'll read it more carefully
when the next draft comes out.)  It may be better to add the
bindings to the user-environment *before* evaluating the body
instead of *after*; however that has some difficulties too.

I suspect there are some conformance issue in the expansion process
(chapter 10 in R6RS - didn't find it in R7RS draft).  But I don't
think it makes a difference in practice.
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/