Again: illegal uses of define in guile

Again: illegal uses of define in guile

[Dirk Herrmann]

Hi folks,

we have been discussing the question of illegal uses of define in guile,
especially code like

  (if <condition> (define foo bar))

and have come to the conclusion that we want to support such code.  Thus,
we have come up with the following conclusions:

> 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.

But, there is one thing about such code which needs to be clarified:  How
should the following code be translated:

  (begin
     (define => 'foo)
     (cond (#t => 'ok)))

According to R5RS the result should be 'ok (see section 4.3.2 pattern
language). This, however, requires some intelligence when handling with
top-level forms:  Top level forms would need to be split up into separate
definitions and expressions before each separate definition and expression
is memoized and executed.  This is easily possible when using the R5RS
restriction that top level definitions may not be used within any
construct except possibly nested within 'begin's.  If we allow top level
definitions also to be performed within 'if's and other stuff, there is
the question, how the following expression should be evaluated:

  (if <condition> 
     (begin
       (define => 'foo))
       (cond (#t => 'ok))))

To handle this in the 'expected' way is difficult:  The form would have to
be split up such that the definition was performed before the syntax
transformation of the cond-expression was performed.  Things can be even
more complicated:

  (if <condition1>
    (begin
      (if <condition2>
         (define => 'foo))
      (cond (#t => 'ok))))

To handle such stuff consistently is quite complicated.  One possible
solution is to never memoize top-level forms, but always interpret them.
Only lambda forms would then be memoized.  This, however, makes evaluating
code quite complicated:  We would need an interpreter of non-memoized top
level forms, and an interpreter for memoized non top level forms.

Hmmm?

Best regards, 
Dirk Herrmann



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