include bug in guile

include bug in guile

[rain1]

I think this is a bug in guile relating to "include":

a.scm: (define a 1)
b.scm: (include "a.scm") (display a) (newline)

guile -l b.scm # prints 1

now update
a.scm: (define a 2)

guile -l b.scm # still prints 1

Re: include bug in guile

[Wette, Matthew R (3441)]

[-- Attachment #1: Type: text/plain, Size: 702 bytes --]


On Mar 29, 2016, at 10:16 AM, rain1@openmailbox.org<mailto:rain1@openmailbox.org> wrote:

I think this is a bug in guile relating to "include":

a.scm: (define a 1)
b.scm: (include "a.scm") (display a) (newline)

guile -l b.scm # prints 1

now update
a.scm: (define a 2)

guile -l b.scm # still prints 1

I have noticed this behavior and have learned to live with it.  Given the following from the Guile Reference manual (2.0.11), I think it is not considered a bug.

"On the other hand, include does have all the disadvantages of early binding: once the code with the include is compiled, no change to the included file is reflected in the future behavior of the including form."


[-- Attachment #2: Type: text/html, Size: 1886 bytes --]

Re: include bug in guile

[Wette, Matthew R (3441)]

[-- Attachment #1: Type: text/plain, Size: 1084 bytes --]


On Mar 29, 2016, at 6:05 PM, Wette, Matthew R (3441) <matthew.r.wette@jpl.nasa.gov<mailto:matthew.r.wette@jpl.nasa.gov>> wrote:


On Mar 29, 2016, at 10:16 AM, rain1@openmailbox.org<mailto:rain1@openmailbox.org> wrote:

I think this is a bug in guile relating to "include":

a.scm: (define a 1)
b.scm: (include "a.scm") (display a) (newline)

guile -l b.scm # prints 1

now update
a.scm: (define a 2)

guile -l b.scm # still prints 1

I have noticed this behavior and have learned to live with it.  Given the following from the Guile Reference manual (2.0.11), I think it is not considered a bug.

"On the other hand, include does have all the disadvantages of early binding: once the code with the include is compiled, no change to the included file is reflected in the future behavior of the including form.”

And I will add that an implementation that checked all includes would have to carry a tree of source dependencies for each binary .go file.  The alternative seems unattractive to me so I am happy to live with the current implementation. — Matt

[-- Attachment #2: Type: text/html, Size: 2545 bytes --]

Re: include bug in guile

[rain1]

On 2016-03-31 13:39, Wette, Matthew R (3441) wrote:
>> On Mar 29, 2016, at 6:05 PM, Wette, Matthew R (3441)
>> <matthew.r.wette@jpl.nasa.gov> wrote:
>> 
>>> On Mar 29, 2016, at 10:16 AM, rain1@openmailbox.org wrote:
>>> 
>>> I think this is a bug in guile relating to "include":
>>> 
>>> a.scm: (define a 1)
>>> b.scm: (include "a.scm") (display a) (newline)
>>> 
>>> guile -l b.scm # prints 1
>>> 
>>> now update
>>> a.scm: (define a 2)
>>> 
>>> guile -l b.scm # still prints 1
>> 
>> I have noticed this behavior and have learned to live with it. Given
>> the following from the Guile Reference manual (2.0.11), I think it
>> is not considered a bug.
>> 
>> "On the other hand, include does have all the disadvantages of early
>> binding: once the code with the include is compiled, no change to
>> the included file is reflected in the future behavior of the
>> including form.”
>  And I will add that an implementation that checked all includes would
> have to carry a tree of source dependencies for each binary .go file.
> The alternative seems unattractive to me so I am happy to live with
> the current implementation. — Matt

I think you are right and this can't be considered a bug, even though it 
may introduce bugs in programming if used wrong.

wingo mentioned to me that LOAD can be used as an alternative to INCLUDE 
if we want late binding instead of early.

Thanks!