guile-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: translators and scoping rules (was: Re: language translator help)


From: John W. Eaton
Subject: Re: translators and scoping rules (was: Re: language translator help)
Date: Mon, 29 Apr 2002 11:27:26 -0500

On 28-Apr-2002, Per Bothner <address@hidden> wrote:

| John W. Eaton wrote:
|
| > The rules are essentially the same as for Fortran.  Variables are
| > local to functions (subroutines).  The only "global" variables are
| > declared global (common).
| 
| What I was referring to was whether the following is defined,
| assuming f(10) is called with no global definition of x:
| 
| function f (x)
|    f = g()
| endfunction
| 
| functioon g()
|    g = x
| endfunction

No, this won't work because X is only defined inside F, not G:

  octave2.1:1> function f (x)
  >   f = g()
  > endfunction
  octave2.1:2> function g()
  >   g = x
  > endfunction
  octave2.1:3> f (1)
  error: `x' undefined near line 2 column 7
  error: evaluating assignment expression near line 2, column 5
  error: called from `g'
  error: called from `f'

Also, variables defined at the top level (command line) are in a
separate namespace that is not the same as the global namespace.
Variables in the top-level namespace are not visible to any function.
So, for example, after the definition of G above,

  octave2.1:3> x = 1
  x = 1
  octave2.1:4> g
  error: `x' undefined near line 2 column 7
  error: evaluating assignment expression near line 2, column 5
  error: called from `g'

The only way for this to work without passing X as an argument to G is
to write

  octave2.1:4> global x
  octave2.1:5> x = 1
  x = 1
  octave2.1:6> function g ()
  >   global x
  >   g = x
  > endfunction
  octave2.1:7> g
  g = 1

So, does it make sense that an Octave translator would be able to
store Octave variables as Guile variables, or would they need to be
stored separately in some tables as Thomas Bushnell said he was doing
for Python?  I see no real problems with that approach, but I was
thinking I might be able to avoid it, and just have Guile manage the
variables.  To avoid conflicts, Octave variables would probably
defined inside a module so that they would be in a separate namespace,
but they would still be Guile variables, not data stored in some
separate tables that my translator would have to manage.

jwe



reply via email to

[Prev in Thread] Current Thread [Next in Thread]