illegal uses of define in guile

illegal uses of define in guile

[Dirk Herrmann]

Hi,

(I have been quiet for some time because I was on vacation.)

with respect to defines and top level forms, I would like to point out the
following issue (which may also be of relevance for the ideas you discuss
in the file new-model.txt, Marius).

Currently, guile allows the following:
  (if (not (defined? '%load-verbosely))
      (define %load-verbosely #f))
as can be found in r4rs.scm.

This is in contrast to R5RS (maybe even already in contrast to R4RS,
but I haven't checked that).  Allowing such placements of define will make
it impossible to determine statically whether after evaluation of the
form the corresponding identifier will be bound or not.  That is, we
should disallow this behaviour.

First, the code in r4rs.scm should be fixed.  However, I have not taken a
closer look at the way %load-verbosely is being used.  Maybe I will get to
this in the next time, but if someone else could take care of it, great.

Second, we should decide about how to deal with such forms.  Since guile
has allowed this before, there may exist code that makes use of this
feature.  It will, however, be difficult to support this feature as
'deprecated' when separating memoization and execution.

Best regards, 
Dirk Herrmann



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: illegal uses of define in guile

[Bruce Korb]

Dirk Herrmann wrote:
> 
> Currently, guile allows the following:
>   (if (not (defined? '%load-verbosely))
>       (define %load-verbosely #f))

I do that.

> This is in contrast to R5RS (maybe even already in contrast to R4RS,
> but I haven't checked that).  Allowing such placements of define will make
> it impossible to determine statically whether after evaluation of the
> form the corresponding identifier will be bound or not.  That is, we
> should disallow this behaviour.

Just because static analysis is hard/difficult/impossible
does not mean you have to disallow the construct.  It may
mean you have to disable "memoization" or "optimization"
of it -- that's okay.  But invalidating peoples work just
because you have an optimization problem, ... well it is
as bad as saying you cannot alias an "intptr_t" with a
pointer in C.

> Second, we should decide about how to deal with such forms.  Since guile
> has allowed this before, there may exist code that makes use of this
> feature.  It will, however, be difficult to support this feature as
> 'deprecated' when separating memoization and execution.

:-(


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: illegal uses of define in guile

[Neil Jerram]

>>>>> "Bruce" == Bruce Korb <bkorb@pacbell.net> writes:

    Bruce> Dirk Herrmann wrote:
    >> 
    >> Currently, guile allows the following:
    >> (if (not (defined? '%load-verbosely))
    >> (define %load-verbosely #f))

    Bruce> I do that.

I do too; however, I guess one could instead write this:

(define %load-verbosely
        (if (defined? '%load-verbosely)
            %load-verbosely
            #f))

Would this work?

        Neil



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: illegal uses of define in guile

[Bruce Korb]

Neil Jerram wrote:

>     >> Currently, guile allows the following:
>     >> (if (not (defined? '%load-verbosely))
>     >> (define %load-verbosely #f))
> 
>     Bruce> I do that.
> 
> I do too; however, I guess one could instead write this:
> 
> (define %load-verbosely
>         (if (defined? '%load-verbosely)
>             %load-verbosely
>             #f))
> 
> Would this work?

Even if it worked in that example, it leaves open:

  (if (some-sort-of-context-test)
      (begin
        (define ....)
        ...
  )   )

'cuz that's where I'd really have my problem.  :-(


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: illegal uses of define in guile

[Dirk Herrmann]

On Mon, 14 Oct 2002, Bruce Korb wrote:

> Neil Jerram wrote:
> 
> >     >> Currently, guile allows the following:
> >     >> (if (not (defined? '%load-verbosely))
> >     >> (define %load-verbosely #f))
> > 
> >     Bruce> I do that.
> > 
> > I do too; however, I guess one could instead write this:
> > 
> > (define %load-verbosely
> >         (if (defined? '%load-verbosely)
> >             %load-verbosely
> >             #f))
> > 
> > Would this work?
> 
> Even if it worked in that example, it leaves open:
> 
>   (if (some-sort-of-context-test)
>       (begin
>         (define ....)
>         ...
>   )   )
> 
> 'cuz that's where I'd really have my problem.  :-(

I wonder what people's objective is when they use these constructs?  Do
you really want to construct two different top-level environments, where
once the symbol has a definition and once it has not?  Are you (mis)using
the definedness of a symbol as a means to communicate boolean values?

Do other scheme implementations allow this?

Best regards
Dirk Herrmann



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: illegal uses of define in guile

[tomas]

On Tue, Oct 15, 2002 at 08:15:17AM +0200, Dirk Herrmann wrote:
> On Mon, 14 Oct 2002, Bruce Korb wrote:
> 
> > Neil Jerram wrote:
> > 
> > >     >> Currently, guile allows the following:
> > >     >> (if (not (defined? '%load-verbosely))
> > >     >> (define %load-verbosely #f))
> > > 
> > >     Bruce> I do that.

[...]

> I wonder what people's objective is when they use these constructs?  Do
> you really want to construct two different top-level environments, where
> once the symbol has a definition and once it has not?  Are you (mis)using
> the definedness of a symbol as a means to communicate boolean values?

I'd second Bruce here. Static code analysis should first make sure that
`important' things are not re-bound, but basically allow anything. If
I loose optimisation, so be it -- but I wouldn't like to lose flexibility.

I understand that the optimiser can't try to guess all the way down
whether `define' has been redefined. It might often fail to the
conservative side. I see two ways to deal with it:

  (a) programmer promises: special forms whereby I swear that this
    thing won't change. Reminds me a bit of C++ :-/
    (but still better than nothing).

  (b) have a look at what those folks do with partial evaluation
    (the general `monster' solution).

  (c) stripped down versions of (b). Is it possible to assume in
    general that some things don't change (and make it possible,
    if more expensive, that they change?) and give the possibility
    of an (external) package which will do the full code analysis
    if requested?

> Do other scheme implementations allow this?

I don't know for sure, but I'd be tempted to state:

  "For all feature f there is a Scheme implementation..."

(you get the idea ;)

Regards
-- tomas


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: illegal uses of define in guile

[rm]

On Mon, Oct 14, 2002 at 07:17:03PM +0200, Dirk Herrmann wrote:
> Hi,
> 
> (I have been quiet for some time because I was on vacation.)
> 
> with respect to defines and top level forms, I would like to point out the
> following issue (which may also be of relevance for the ideas you discuss
> in the file new-model.txt, Marius).
> 
> Currently, guile allows the following:
>   (if (not (defined? '%load-verbosely))
>       (define %load-verbosely #f))
> as can be found in r4rs.scm.
> 
> This is in contrast to R5RS (maybe even already in contrast to R4RS,
> but I haven't checked that).  Allowing such placements of define will make
> it impossible to determine statically whether after evaluation of the
> form the corresponding identifier will be bound or not.  That is, we
> should disallow this behaviour.

Hmm, doesn't the above imply that the side-effect' of 'define' is static?
What about code like the following:

  (use-module (ice-9 safe))

  (define my-context (current-module))

  (if some-weird-condition
      (set! my-context (make-safe-module)))

  ;; the side-effect of define here will depend on
  ;; the boolean interpretation of 'some-weird-condition'

  (eval (define car #f) my-context)

  ;; or, even meaner ...
  (define (nodefine sym val)
    (display "Safe environ: no (re)definition allowed!\n"))

  (eval (define  define nodefine) my-context)

Maybe a bit constructed but i can well imagine similar usefull situations.

 Ralf Mattes


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: illegal uses of define in guile

[rm]

On Tue, Oct 15, 2002 at 08:15:17AM +0200, Dirk Herrmann wrote:
> [...]
> I wonder what people's objective is when they use these constructs?  Do
> you really want to construct two different top-level environments, where
> once the symbol has a definition and once it has not?  Are you (mis)using
> the definedness of a symbol as a means to communicate boolean values?
> 
> Do other scheme implementations allow this?
> 

Just a short testrun:

drscheme - no
elk      - yes
scheme48 - no
kali     - no
stalin   - no
bigloo   - yes

 Greetings 

     Ralf Mattes
 
> Best regards
> Dirk Herrmann
> 
> 
> 
> _______________________________________________
> Guile-devel mailing list
> Guile-devel@gnu.org
> http://mail.gnu.org/mailman/listinfo/guile-devel


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: illegal uses of define in guile

[Bruce Korb]

Dirk Herrmann wrote:

> >   (if (some-sort-of-context-test)
> >       (begin
> >         (define mumble ....)
> >         ...
> >   )   )
> >
> > 'cuz that's where I'd really have my problem.  :-(
> 
> I wonder what people's objective is when they use these constructs?

My guess is that you are thinking about a program written entirely
in Scheme.  In my context, I have a list of things that need doing,
among them defining a scheme value that may even be derived from
non-scheme information.  Later on, I'll test ``(some-sort-of-context-test)''
or, even, whether or not "mumble" got defined in order to decide
about what to do.  This "later on" occurrs in a completely different
part of my program.  Remember, this all gets embedded in the context
of an encompassing program.

> Do
> you really want to construct two different top-level environments, where
> once the symbol has a definition and once it has not?  Are you (mis)using
> the definedness of a symbol as a means to communicate boolean values?

Sometimes.  Not usually, though, but given that the function
(defined? ...) exists, I've used it to decide program flow.


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: illegal uses of define in guile

[Marius Vollmer]

Dirk Herrmann <dirk@sallust.ida.ing.tu-bs.de> writes:

> Currently, guile allows the following:
>   (if (not (defined? '%load-verbosely))
>       (define %load-verbosely #f))
> as can be found in r4rs.scm.
> 
> This is in contrast to R5RS (maybe even already in contrast to R4RS,
> but I haven't checked that).  Allowing such placements of define will make
> it impossible to determine statically whether after evaluation of the
> form the corresponding identifier will be bound or not.  That is, we
> should disallow this behaviour.

I think we can continue to support it, when people really want us to.
The new.model.txt needs to be adapted a bit, but not much, I think.

This will affect the optimizations a compiler might make, of course,
and maybe we should warn people that such uses of 'define' are
questionable.  We can also disallow them in 'R5RS' mode, when we have
such a thing.

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: illegal uses of define in guile

[Dirk Herrmann]

Hi,

as far as I understand it, we want to further allow uses of define as in
the following situation:

> (if (not (defined? '%load-verbosely))
>     (define %load-verbosely #f))

You have convinced me, since I now have understood the following:  We must
be able to handle non-bound identifiers during compilation anyway.  Such
identifiers may legally become bound later, for example because of some
use of 'eval or 'load.  For example, the compiler has to be able to emit
code for

(define (foo) bar)

even if bar was not yet defined at that time.  Only when foo gets
evaluated, bar has to be defined.  Allowing

> (if (not (defined? '%load-verbosely))
>     (define %load-verbosely #f))

relies on this fact.  However, it even goes somewhat further:  It requires
that the executor must be able to handle definitions.

As said above, I agree that we can do this.  However, we should make one
thing sure:  Once a binding has been referenced, the binding itself should
never change.  Otherwise, memoizing lookups of identifiers in a top-level
environment could never be done (or would require to use some logic to
undo memoization whenever a binding changes).  IMO it is better to define
the system such that re-binding of identifiers is not allowed.

Summarized:
* The compiler must be able to emit code that allows references to
  identifiers to be looked up at use time (that is, in the executor).
* The executor must be able to handle definitions.
* Once a binding has been referenced, the binding should not change.

Best regards,
Dirk Herrmann



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: illegal uses of define in guile

[Marius Vollmer]

Dirk Herrmann <dirk@sallust.ida.ing.tu-bs.de> writes:

> Summarized:
> * The compiler must be able to emit code that allows references to
>   identifiers to be looked up at use time (that is, in the executor).
> * The executor must be able to handle definitions.
> * Once a binding has been referenced, the binding should not change.

Yes, that's exactly the way I see it as well.  The constraints that
new-model.txt puts on the module system work in this direction.

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: illegal uses of define in guile

[tomas]

On Sat, Oct 19, 2002 at 05:22:03PM +0200, Dirk Herrmann wrote:

[...]

> Summarized:
> * The compiler must be able to emit code that allows references to
>   identifiers to be looked up at use time (that is, in the executor).
> * The executor must be able to handle definitions.
> * Once a binding has been referenced, the binding should not change.

Is this going to be enforced at run time somehow (says he with a
little evil grin) -- or does a change on an once-referenced binding
result in undefined behaviour?

In the first case there could be a hook for those interested in
`fixing' the memoization. Then you would have the best of both
worlds -- paying an extra penalty if you decide to do quirky
things. In the second case, well...

Thinking about it, even this is something the compiler could
emit optionally.

(Don't take my rants too serioulsy though -- I'm far from actually
playing around with the compiler).

Regards
-- tomas


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: illegal uses of define in guile

[Marius Vollmer]

tomas@fabula.de writes:

> On Sat, Oct 19, 2002 at 05:22:03PM +0200, Dirk Herrmann wrote:
> 
> [...]
> 
> > Summarized:
> > * The compiler must be able to emit code that allows references to
> >   identifiers to be looked up at use time (that is, in the executor).
> > * The executor must be able to handle definitions.
> > * Once a binding has been referenced, the binding should not change.
> 
> Is this going to be enforced at run time somehow (says he with a
> little evil grin) -- or does a change on an once-referenced binding
> result in undefined behaviour?

It will be enforced at run-time (according to my current plan, anyway,
see workbook/compiler/new-model.text), simply by not allowing changes
to modules that would change the outcome of lookups.  That is, you can
not remove bindings, or redirect them.

> In the first case there could be a hook for those interested in
> `fixing' the memoization. Then you would have the best of both
> worlds -- paying an extra penalty if you decide to do quirky
> things. In the second case, well...

When you do quirky things, would be OK to require you to reload code
that is affected by this?  Guile can help by offering a list of files
that would need to be reloaded.

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: illegal uses of define in guile

[tomas]

On Sun, Nov 03, 2002 at 05:28:35PM +0100, Marius Vollmer wrote:
> tomas@fabula.de writes:
> 
> > On Sat, Oct 19, 2002 at 05:22:03PM +0200, Dirk Herrmann wrote:
> > 
> > [...]
> > 
> > > Summarized:
> > > * The compiler must be able to emit code that allows references to
> > >   identifiers to be looked up at use time (that is, in the executor).
> > > * The executor must be able to handle definitions.
> > > * Once a binding has been referenced, the binding should not change.
> > 
> > Is this going to be enforced at run time somehow [...]

> It will be enforced at run-time [...]

> When you do quirky things, would be OK to require you to reload code
> that is affected by this?  Guile can help by offering a list of files
> that would need to be reloaded.

Yes, that sounds fine: you don't pay a very high penalty in the `fast
path' (i.e. in the optimized code), but you get the flexibility if you
are willing to pay the price. It is clear that you have to reload things
if bindings change, I think.

Thanks
-- tomas


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel