Dynamic variable binding

Dynamic variable binding

[Sebastian Tennant]

Hi all,

An elementary scheme problem from an elementary schemer...

I need to create multiple variable bindings from a list of symbols.  The
value of the variables is unimportant.  It's the 'names' of the
variables that matter.

In pseudo-scheme code:

  (map (lambda (v) (define (eval v) "foo") '(var1 var2 var3)))

Clearly this won't work but I thought perhaps calling a macro in place
of the 'define' would do it, but...

 guile> (define-macro (definer var val)
          `(define ,var ,val))
 guile> (definer 'foo "bar")
 guile> foo
 ERROR: Unbound variable: foo
 ABORT: (unbound-variable)

No doubt this fails for the same reason this does:

 guile> (define 'foo "bar")
 guile> foo
 ERROR: Unbound variable: foo
 ABORT: (unbound-variable)

What exactly happens when you 'define' a symbol?

Any tips/pointers much appreciated.

Sebastian

Re: Dynamic variable binding

[Ludovic Courtès]

Hello!

Sebastian Tennant <sebyte@smolny.plus.com> writes:

> What exactly happens when you 'define' a symbol?

In Guile (non-portable) terms, "(define foo 'bar)" is equivalent to:

  (module-define! (current-module) 'foo 'bar)

or, at a lower-level:

  (module-add! (current-module) 'foo (make-variable 'bar))

But, just like "`eval' is evil", run-time symbol definition doesn't
sound right.  Surely, there are other ways that you could use to solve
your problem more elegantly.

Thanks,
Ludo'.

Re: Dynamic variable binding

[dsmich]

---- "Ludovic Courtès" <ludo@gnu.org> wrote: 
> Sebastian Tennant <sebyte@smolny.plus.com> writes:
> > What exactly happens when you 'define' a symbol?
> 
> But, just like "`eval' is evil", run-time symbol definition doesn't
> sound right.  Surely, there are other ways that you could use to solve
> your problem more elegantly.

Sebastian,  instead of trying to use Guiles symbol and module namespaces as a hashtable, why not just use a hashtable directly?  ;^)

-Dale

Re: Dynamic variable binding

[Keith Wright]

> From: Sebastian Tennant <sebyte@smolny.plus.com>
>
>  guile> (define-macro (definer var val)
>           `(define ,var ,val))
>  guile> (definer 'foo "bar")
>  guile> foo
>  ERROR: Unbound variable: foo
>  ABORT: (unbound-variable)
> 
> No doubt this fails for the same reason this does:
> 
>  guile> (define 'foo "bar")
>  guile> foo
>  ERROR: Unbound variable: foo
>  ABORT: (unbound-variable)
> 
> What exactly happens when you 'define' a symbol?

I don't know what happens (in Guile), but I can tell
you what _should_ happen.  (In my humble opinion as
a demi-god of semantics.)

Scheme> (define 'foo "bar")

at a very early stage (like in the reader) this is

Scheme> (define (quote foo) "bar")

There are several possiblities

(1) error message in define
  (1a) Rude: Thou fool! |quote| is not a variable
  (1b) Polite: If you are sure you want to do that,
       write out the quote, don't use apostrophe
  (1c) Obscure: Bad variable in def_schkdt

(2) Redefine quote
  (2a) In a new local scope: 'a is a call to procedure
       |quote| with argument the value of |a|, argument is
       evaluated, ignored, and 'a -> "bar" if |a| is defined.
  (2b) Hell breaks loose: All uses of |quote| in previously
       defined system procedures now have a new meaning.
       e.g. depending on exact code for |abs|, maybe
       (abs -3) -> "bar"

But you are asking the wrong question.  Ask not
what happens when a symbol is defined, ask what
you can do to make the macro define an unquoted
variable.

   -- Keith

PS: Experiments with an old version of Guile indicate (2).
To distinguish (2a) from (2b) would require work or knowledge.

guile> (version)
"1.6.4"
guile>  (define 'foo "bar")
guile> (quote 3)
"bar"
guile> '3
"bar"
guile> 'foo
standard input:6:4096: While evaluating arguments to quote in expression (quote foo):
standard input:6:4096: Unbound variable: foo
ABORT: (unbound-variable)

Re: Dynamic variable binding

[Sebastian Tennant]

Quoth Sebastian Tennant <sebyte@smolny.plus.com>:
Hi all,

Many thanks to all responders, especially to Ludo' for answering my
question directly.

The macro definition I was searching for is simply this:

 (define-macro (definer var val) ;var must be a symbol
   `(module-define! (current-module) ,var ,val))

Wrapped within a 'for-each' this macro allows me to bind as many
variables as a like in a single stroke.

Why not use the module namespace as a top-level hash table Dale?  Isn't
that essentially what a module namespace is, or at least what it's for?

Is there a really good reason to avoid doing this?

Apart from non-portablility, what difference does it make whether a
variable is bound using 'define' or my 'definer' macro?

Thanks once again.

Sebastian

Re: Dynamic variable binding

[Kjetil S. Matheussen]

Sebastian Tennant:
>
> Hi all,
>
> An elementary scheme problem from an elementary schemer...
>
> I need to create multiple variable bindings from a list of symbols.  The
> value of the variables is unimportant.  It's the 'names' of the
> variables that matter.
>
> In pseudo-scheme code:
>
>  (map (lambda (v) (define (eval v) "foo") '(var1 var2 var3)))
>
> Clearly this won't work but I thought perhaps calling a macro in place
> of the 'define' would do it, but...
>

That's a common problem.
Maybe this is one good enough:

(define-macro (define-lotsof names value)
    `(begin
       ,@(map (lambda (name)
                 `(define ,name ,value))
              names)))

(define-lotsof (a b c) "foo")

If not, you may need to play with local-eval or similar.

Re: Dynamic variable binding

[Ludovic Courtès]

Hello,

Sebastian Tennant <sebyte@smolny.plus.com> writes:

> The macro definition I was searching for is simply this:
>
>  (define-macro (definer var val) ;var must be a symbol
>    `(module-define! (current-module) ,var ,val))
>
> Wrapped within a 'for-each' this macro allows me to bind as many
> variables as a like in a single stroke.
>
> Why not use the module namespace as a top-level hash table Dale?  Isn't
> that essentially what a module namespace is, or at least what it's for?
>
> Is there a really good reason to avoid doing this?

Dynamic binding definition is compilation-unfriendly.  Kjetil's proposed
`define-lotsof' macro is more appropriate, as it can be fully evaluated
at compile-time (should a compiler be used, that is), whereas the
`module-define!' trick requires that compilation and execution be the
one and same phase.

Thanks,
Ludo'.

Re: Dynamic variable binding

[Sebastian Tennant]

Quoth ludo@gnu.org (Ludovic Courtès):
> Dynamic binding definition is compilation-unfriendly.  Kjetil's
> proposed `define-lotsof' macro is more appropriate, as it can be fully
> evaluated at compile-time (should a compiler be used, that is),
> whereas the `module-define!' trick requires that compilation and
> execution be the one and same phase.

Ah, interesting.  Noted.  Thanks again (to Kjetil also).

Sebastian

Re: Dynamic variable binding

[Jon Wilson]

Sebastian Tennant wrote:
> Quoth ludo@gnu.org (Ludovic Courtès):
>> Dynamic binding definition is compilation-unfriendly.  Kjetil's
>> proposed `define-lotsof' macro is more appropriate, as it can be fully
>> evaluated at compile-time (should a compiler be used, that is),
>> whereas the `module-define!' trick requires that compilation and
>> execution be the one and same phase.
> 
> Ah, interesting.  Noted.  Thanks again (to Kjetil also).

Furthermore, the lack of separation between what is compiled and what is 
executed causes problems with defining a module system that understands 
hygiene.  It took me a while to understand this, but finally sitting 
down and grokking Matthew Flatt's paper "Compilable and Composable 
Macros: You Want it When?" got it through my skull.

http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.11.4008

Regards,
Jon

Re: Dynamic variable binding

[Sebastian Tennant]

Quoth Jon Wilson <jsw@wilsonjc.us>:
> Sebastian Tennant wrote:
>> Quoth ludo@gnu.org (Ludovic Courtès):
>>> Dynamic binding definition is compilation-unfriendly.  Kjetil's
>>> proposed `define-lotsof' macro is more appropriate, as it can be fully
>>> evaluated at compile-time (should a compiler be used, that is),
>>> whereas the `module-define!' trick requires that compilation and
>>> execution be the one and same phase.
>>
>> Ah, interesting.  Noted.  Thanks again (to Kjetil also).
>
> Furthermore, the lack of separation between what is compiled and what
> is executed causes problems with defining a module system that
> understands hygiene.  It took me a while to understand this, but
> finally sitting down and grokking Matthew Flatt's paper "Compilable
> and Composable Macros: You Want it When?" got it through my skull.
>
> http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.11.4008

This looks like a very useful (and comprehensive) paper.  Thanks.

Sebastian

Re: Dynamic variable binding

[Sebastian Tennant]

> Quoth Keith Wright <kwright@keithdiane.us>:
>> From: Sebastian Tennant <sebyte@smolny.plus.com>
>>
>>  guile> (define-macro (definer var val)
>>           `(define ,var ,val))
>>  guile> (definer 'foo "bar")
>>  guile> foo
>>  ERROR: Unbound variable: foo
>>  ABORT: (unbound-variable)
>> 
>> No doubt this fails for the same reason this does:
>> 
>>  guile> (define 'foo "bar")
>>  guile> foo
>>  ERROR: Unbound variable: foo
>>  ABORT: (unbound-variable)
>> 
>> What exactly happens when you 'define' a symbol?

> I don't know what happens (in Guile), but I can tell
> you what _should_ happen.  (In my humble opinion as
> a demi-god of semantics.)

I'm trying to wrap my head around symbols, variables and names of
variables.  They seem to me to be three different things.

> (define 'foo "bar")
>
> There are several possibilities
>
> (1) error message in define
>   (1a) Rude: Thou fool! |quote| is not a variable
>   (1b) Polite: If you are sure you want to do that,
>        write out the quote, don't use apostrophe
>   (1c) Obscure: Bad variable in def_schkdt

To be really semantically accurate should we not say:

(1a) Thou irrepressible fool! |quote| cannot be the _name_ of a variable.
(1c) Obscure: Bad variable _name_ in def_schkdt.

> But you are asking the wrong question.  Ask not
> what happens when a symbol is defined, ask what
> you can do to make the macro define an unquoted
> variable.

Answer: Pass it an unquoted variable.

 (define-macro (definer var val)
   `(define ,var ,val))
 =>
 (definer foo "bar")
 =>
 foo
 => "bar"

 :)

Is that the answer you expected?

My semantic point is that the first argument to definer (above) is not a
symbol and it's not a variable (an unbound variable error would be
thrown if it was), so in the context of the first agument to define
there is a third data type; 'variable name'.

Sebastian

Re: Dynamic variable binding

[Ludovic Courtès]

Hi,

Sebastian Tennant <sebyte@smolny.plus.com> writes:

> My semantic point is that the first argument to definer (above) is not a
> symbol and it's not a variable (an unbound variable error would be
> thrown if it was), so in the context of the first agument to define
> there is a third data type; 'variable name'.

Beware: the term "variable" can refer to an object as returned by
`make-variable', `module-variable', etc., in Guile parlance (info
"(guile) Variables").

What happens with your `definer' macro is that the first argument of the
macro is a symbol (that is, during the *macro expansion* phase).  The
result of `definer' (an sexp) is then itself evaluated, so that symbol
becomes a reference to a variable (during the evaluation phase).

Thanks,
Ludo'.

Re: Dynamic variable binding

[Sebastian Tennant]

Quoth ludo@gnu.org (Ludovic Courtès):
> Hi,
>
> Sebastian Tennant <sebyte@smolny.plus.com> writes:
>
>> My semantic point is that the first argument to definer (above) is not a
>> symbol and it's not a variable (an unbound variable error would be
>> thrown if it was), so in the context of the first agument to define
>> there is a third data type; 'variable name'.
>
> Beware: the term "variable" can refer to an object as returned by
> `make-variable', `module-variable', etc., in Guile parlance (info
> "(guile) Variables").

Noted.

> What happens with your `definer' macro is that the first argument of the
> macro is a symbol (that is, during the *macro expansion* phase).  The
> result of `definer' (an sexp) is then itself evaluated, so that symbol
> becomes a reference to a variable (during the evaluation phase).

Thanks for your input Ludo.

I can't say I've fully grokked it yet but I'm spending _far_ too much
time on this, so I'm going to let it go for now :)

Seb

Re: Dynamic variable binding

[Keith Wright]

> From: Sebastian Tennant <sebyte@smolny.plus.com>
> 
> > Quoth Keith Wright <kwright@keithdiane.us>:
> 
> > I don't know what happens (in Guile), but I can tell
> > you what _should_ happen.  (In my humble opinion as
> > a demi-god of semantics.)
> 
> I'm trying to wrap my head around symbols, variables
> and names of variables.  They seem to me to be three
> different things.

NB: I hate emoticons.  The lack of a smiley face does
not imply seriousness.  This sort of thing has been
puzzling a lot of people for a long time.  In particular,
I published a paper about it some 25 years ago, but have
since decided that I don't know enough to be publishing.
That's why it's fun to rave on the mailing list.

> > (define 'foo "bar")
> >
> > There are several possibilities
> >
> > (1) error message in define
> >   (1a) Rude: Thou fool! |quote| is not a variable
> >   (1b) Polite: If you are sure you want to do that,
> >        write out the quote, don't use apostrophe
> >   (1c) Obscure: Bad variable in def_schkdt
> 
> To be really semantically accurate should we not say:
> 
> (1a) Thou irrepressible fool! |quote| cannot be
>      the _name_ of a variable.
> (1c) Obscure: Bad variable _name_ in def_schkdt.

I almost understand something about symbols and variables,
but the _name_ of a variable is not a technical term.
I don't name variables, I just call them "this variable"
or "that variable", or sometimes describe them as
the "local variable |foo|".

> > But you are asking the wrong question.  Ask not
> > what happens when a symbol is defined, ask what
> > you can do to make the macro define an unquoted
> > variable.
> 
> Answer: Pass it an unquoted variable.
> 
> Is that the answer you expected?

I am not sure I expected it, but it makes me feel good
to know that it works.

> My semantic point is that the first argument to
> definer (above) is not a symbol and it's not a
> variable (an unbound variable error would be thrown
> if it was), so in the context of the first agument to
> define there is a third data type; 'variable name'.

I am quite sure that it _is_ a variable, because the
Scheme report, in the section on Variable Definitions,
says:

   (define <variable> <expression>)
   ...define binds <variable> to a new location...

you yourself say "pass it an unquoted variable".

There is no unbound variable error, because the
whole point of |define| is to bind a variable.
It expects an unbound variable, but it must be
a variable or else it would not become a bound
variable after the |define| form binds it.

  -- Keith

"The name of the song is called 'Haddocks' eyes'."
"Oh, that's the name of the song, is it?"
 Alice said.
"No, you don't understand," the Knight said, looking
 a little vexed.
"That's what the name is _called_."

  -- Lewis Carroll, Through the Looking Glass and
     what Alice found there (1871)

Re: Dynamic variable binding

[Sebastian Tennant]

Quoth Keith Wright <kwright@keithdiane.us>:
>> From: Sebastian Tennant <sebyte@smolny.plus.com>
>>> Quoth Keith Wright <kwright@keithdiane.us>:

>>> I don't know what happens (in Guile), but I can tell
>>> you what _should_ happen.  (In my humble opinion as
>>> a demi-god of semantics.)

>> I'm trying to wrap my head around symbols, variables
>> and names of variables.  They seem to me to be three
>> different things.

> NB: I hate emoticons.  The lack of a smiley face does
> not imply seriousness.  This sort of thing has been
> puzzling a lot of people for a long time.  In particular,
> I published a paper about it some 25 years ago, but have
> since decided that I don't know enough to be publishing.
> That's why it's fun to rave on the mailing list.

So... you're not a demi-god of semantics.  Damn.  I told all my friends
that you were.

> I almost understand something about symbols and variables, but the
> _name_ of a variable is not a technical term.  I don't name variables,
> I just call them "this variable" or "that variable", or sometimes
> describe them as the "local variable |foo|".

>>> But you are asking the wrong question.  Ask not what happens when a
>>> symbol is defined, ask what you can do to make the macro define an
>>> unquoted variable.

>> Answer: Pass it an unquoted variable.
>> 
>> Is that the answer you expected?

> I am not sure I expected it, but it makes me feel good to know that it
> works.

Pleased to be of service.

>> My semantic point is that the first argument to definer (above) is
>> not a symbol and it's not a variable (an unbound variable error would
>> be thrown if it was), so in the context of the first agument to
>> define there is a third data type; 'variable name'.
>
> I am quite sure that it _is_ a variable, because the Scheme report, in
> the section on Variable Definitions, says:
>
>    (define <variable> <expression>)
>    ...define binds <variable> to a new location...
>
> you yourself say "pass it an unquoted variable".

I thought about this obvious contradiction but decided the pith
outweighed the loss.

> "The name of the song is called 'Haddocks' eyes'."  "Oh, that's the
> name of the song, is it?"  Alice said.  "No, you don't understand,"
> the Knight said, looking a little vexed.  "That's what the name is
> _called_."

I wonder what song it was to which Haddock's Eyes referred.

Sebastian

Re: Dynamic variable binding

[Neil Jerram]

2008/12/27 Sebastian Tennant <sebyte@smolny.plus.com>:
> Quoth Keith Wright <kwright@keithdiane.us>:
>
>> "The name of the song is called 'Haddocks' eyes'."  "Oh, that's the
>> name of the song, is it?"  Alice said.  "No, you don't understand,"
>> the Knight said, looking a little vexed.  "That's what the name is
>> _called_."
>
> I wonder what song it was to which Haddock's Eyes referred.

I'm not sure if you're being tongue-in-cheek here or not....

If you are, the answer (as far as I remember) is that Alice and the
Knight didn't mention anything about referring to.

If you're not, the answer is that it's the poem beginning (from
memory) "I saw an aged, aged man, a-sitting on a gate".

Regards,
      Neil

Re: Dynamic variable binding

[Sebastian Tennant]

Quoth "Neil Jerram" <neiljerram@googlemail.com>:
> 2008/12/27 Sebastian Tennant <sebyte@smolny.plus.com>:
>> Quoth Keith Wright <kwright@keithdiane.us>:
>>
>>> "The name of the song is called 'Haddocks' eyes'."  "Oh, that's the
>>> name of the song, is it?"  Alice said.  "No, you don't understand,"
>>> the Knight said, looking a little vexed.  "That's what the name is
>>> _called_."
>>
>> I wonder what song it was to which Haddock's Eyes referred.
>
> I'm not sure if you're being tongue-in-cheek here or not....

I am, and I'm not.

> If you are, the answer (as far as I remember) is that Alice and the
> Knight didn't mention anything about referring to.

Ha! :)  I'm not even going to try and counter that argument.

> If you're not, the answer is that it's the poem beginning (from
> memory) "I saw an aged, aged man, a-sitting on a gate".

That's it!  I've had enough.  I'm going to go home and find my copy.  I
can't bear it any longer :)

Seb