Compilers - Explicit or implicit declaration and inference

Author

Explicit or implicit declaration and inference

Avatar

2006-10-19, 7:01 pm

I am designing a dynamic object-oriented interpreted programming
language. I have some questions concerning the implementation of
dynamic variables.

The general architecture of this interpreted language is similar to
most "scripting" languages. Source files are compiled into bytecode,
which is then extecuted within the context of a VM.

The language implements a dynamic type system (a variable's type is
defined when it is assigned a value), which supports four classes of
variables: Global, Local, Class (or static; variables shared among all
instances of a class), and Instance (or object; variables that are
specific to an instance of a class).

Here is where some of the confusion begins... Are variables explicitly
or implicitly declared?

For discussion purposes let's take a look at how Ruby implements
implicitly declared variables.

Ruby defines the context a variables using a naming convention: Local
variables begin with a single lowercase letter (myvar), Global
variables begin with a $ sign ($myvar), Class variables begin with
double @@ signs (@@myvar), and Instance variables begin with a single @
sign (@myvar). There are rules that prohibit runtime references to
variables that have yet to be assigned a value (implicit declaration)
and so forth... This model seems to work because the compiler is able
to generate the appropriate instructions to deal with setting & getting
variables. If the compiler sees a variable prefaced by an @ sign
(@myvar), it generates an instruction to get an instance variable named
myvar. The VM in turn (when executing the bytecode) would know to
search the appropriate instance variable storage location for its
value.

But what if variables in Ruby did not use a strict naming convention
for variable classes? How would the compiler know which instructions to
generate (get: local, global, class, or instance)? It wouldn't. The
varaible class would need to be "discovered" at runtime. Everytime a
variable was referenced the VM would need to check if there is a
global, local, class, or instance variable defined by that name.

A solution to this problem might involve providing a means to explicity
declare variables. The declaration of a variable would not specify the
variable type, but it would define the variable class (ie. local myvar,
global myvar, ...). Does this really solve the problem though? Not
really. Given that this language is designed with the goal of being
completely dynamic -- this solution fails in some levels. The compiler
in some situations will have enough information to determine the class
of a variable (if it sees a variable declaration), but in other cases
won't (code the compiled on the fly, code that references variables
that were declared in differnent source files).

Maybe I have answered my own question... In order for this language to
fulfill its goal of being truly dynamic it needs to support implcit
declaration of variables where the class of variable can be derived
from the name. I don't see any other alternatives. Does anybody else?

Hans Aberg

2006-10-21, 4:04 am

"Avatar" <acampbellb@hotmail.com> wrote:

> I am designing a dynamic object-oriented interpreted programming
> language. I have some questions concerning the implementation of
> dynamic variables.
.....
> ...what if variables in Ruby did not use a strict naming convention
> for variable classes? How would the compiler know which instructions to
> generate (get: local, global, class, or instance)?

Just make it into a declarative language. One then writes (say)
_ constant <name1>
_ variable <name2>
_ class <name3>
and so on. The implementation is straightforward. When a definition of a
name comes by, store on the lookup table that the lexer checks, also its
grammatical type (constant, variable, class, etc.), which the lexer
returns to the parser. It does not really matter whether the type is
dynamic or not - that is a question for the compiler/interpreter to figure
out a suitable implementation. It is also possible to mix dynamic and
static types. For example:
_ string x_ = ..._ -- Static type.
_ variable y._ _ _ -- Dynamic type.
_ y := x._ _ _ _ _ -- Always valid.
_ x := y._ -- Requires either a check and/or conversion of types, which
_ _ _ _ _ _-- can be dynamic or static (static check would make it illegal).

--
Hans Aberg

Sponsored Links