Explicit or implicit declaration and inference

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

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?

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

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

Whay do you mean by dynamic variables:

- dynamically typed variables?
- dynamically scoped variables?
- dynamically created object fields?
- implicitly defined local variables?
- something else?

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

Well, some languages do the former, some do the latter.

Making variable definitions implicit is problematic with nested
functions. For example when a variable is assigned to only in the
body of a loop, and it's referenced by a local function in that loop,
is there a separate variable for each loop iteration, or do the whole
outer function invocation share a single variable?

In Ruby the answer is inconsistent depending on whether the loop is
a builtin loop (e.g. 'while') or a method with a block (e.g. 'each').

> Given that this language is designed with the goal of being
> completely dynamic

What does it mean to be "completely dynamic"? It's quite meaningless
for me.

--
__("< Marcin Kowalczyk
\__/ qrczak@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/

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

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

Whay do you mean by dynamic variables:

- dynamically typed variables?
- dynamically scoped variables?
- dynamically created object fields?
- implicitly defined local variables?
- something else?

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

Well, some languages do the former, some do the latter.

Making variable definitions implicit is problematic with nested
functions. For example when a variable is assigned to only in the
body of a loop, and it's referenced by a local function in that loop,
is there a separate variable for each loop iteration, or do the whole
outer function invocation share a single variable?

In Ruby the answer is inconsistent depending on whether the loop is
a builtin loop (e.g. 'while') or a method with a block (e.g. 'each').

> Given that this language is designed with the goal of being
> completely dynamic

What does it mean to be "completely dynamic"? It's quite meaningless
for me.

--
__("< Marcin Kowalczyk
\__/ qrczak@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/

"Avatar" <acampbellb@hotmail.com> wrote in message
news:1161339745.852841.37580@b28g2000cwb.googlegro ups.com...
>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?
>

my opinion is that explicit declaration is better.

more so, the scope is often determined by where the variable is declared:

int foo; //global

class bar {
int foo; //class
}

int baz(int x)
{
int foo; //local
}

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

imo, this is ugly.


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

often if it can't be inferred statically, this is what is done.

we can be optimistic:
if the location of the variable can be determined at compile time, we can
use a specific opcode to fetch the variable;
otherwise, the variable is searched for.


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

well, I don't believe that the problem is all that great, or at least if one
is compiling and running in around the same timeframe (implied by the
emphasis on "dynamic" all over the place).

as such, on compilation, we check if the variable is already bound in some
known location, and if so we can refer to it directly, otherwise an indirect
reference could be generated.


another alternative is a module system, but this may imply certain rules
(eg: non-cyclic module dependencies).



however, a personal view of language design:
it is often better to lean on the side of flexibility and generality at a
possible cost to speed, than to have arbitrary behavior or rules regarding
language semantics or features (in the name of performance).

for example, though a little more work, it is often possible to optimize for
special cases anyways (eg: when it 'just happens' that a variable is
statically declared in the local scope, or when it 'just happens' that the
compiler can figure out that an expression always evaluates to an integer,
....).

adding together a bunch of special cases, and optimizing for the common
cases, can seemingly often more than make up for what could have been gained
by hindering the language with arbitrary restrictions (as counterintuitive
as that may seem).

or such...

"Avatar" <acampbellb@hotmail.com> wrote in message
news:1161339745.852841.37580@b28g2000cwb.googlegro ups.com...
>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?
>

my opinion is that explicit declaration is better.

more so, the scope is often determined by where the variable is declared:

int foo; //global

class bar {
int foo; //class
}

int baz(int x)
{
int foo; //local
}

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

imo, this is ugly.


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

often if it can't be inferred statically, this is what is done.

we can be optimistic:
if the location of the variable can be determined at compile time, we can
use a specific opcode to fetch the variable;
otherwise, the variable is searched for.


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

well, I don't believe that the problem is all that great, or at least if one
is compiling and running in around the same timeframe (implied by the
emphasis on "dynamic" all over the place).

as such, on compilation, we check if the variable is already bound in some
known location, and if so we can refer to it directly, otherwise an indirect
reference could be generated.


another alternative is a module system, but this may imply certain rules
(eg: non-cyclic module dependencies).



however, a personal view of language design:
it is often better to lean on the side of flexibility and generality at a
possible cost to speed, than to have arbitrary behavior or rules regarding
language semantics or features (in the name of performance).

for example, though a little more work, it is often possible to optimize for
special cases anyways (eg: when it 'just happens' that a variable is
statically declared in the local scope, or when it 'just happens' that the
compiler can figure out that an expression always evaluates to an integer,
....).

adding together a bunch of special cases, and optimizing for the common
cases, can seemingly often more than make up for what could have been gained
by hindering the language with arbitrary restrictions (as counterintuitive
as that may seem).

or such...

On Fri, Oct 20, 2006 at 03:22:26AM -0700, Avatar wrote:

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

Well, I don't see why you would want variable declarations to be
implicit. Explicitly declaring variables eliminates the possibility for
confusion about scope (is this an assignment to a variable from an outer
scope, or the introduction of a new variable?) and doesn't have to cost
you anything extra (in terms of tokens or characters that you need to
type).

Regards,

Bob

---
A good traveler has no fixed plans, and is not intend on arriving.
-- Lao Tze

On Fri, Oct 20, 2006 at 03:22:26AM -0700, Avatar wrote:

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

Well, I don't see why you would want variable declarations to be
implicit. Explicitly declaring variables eliminates the possibility for
confusion about scope (is this an assignment to a variable from an outer
scope, or the introduction of a new variable?) and doesn't have to cost
you anything extra (in terms of tokens or characters that you need to
type).

Regards,

Bob

---
A good traveler has no fixed plans, and is not intend on arriving.
-- Lao Tze

"Robbert Haarman" <comp.lang.misc@inglorion.net> wrote in message
news:20061022224124.GL18480@morgenes.shire.sytes.n et...
> On Fri, Oct 20, 2006 at 03:22:26AM -0700, Avatar wrote:
>
>> 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?
>
> Well, I don't see why you would want variable declarations to be
> implicit. Explicitly declaring variables eliminates the possibility for
> confusion about scope (is this an assignment to a variable from an outer
> scope, or the introduction of a new variable?) and doesn't have to cost
> you anything extra (in terms of tokens or characters that you need to
> type).
>

yes, I will agree here.

actually, in my lang, I intend to require definitions in all cases,
eventually.

right now, however, they are only required in some cases.
part of the reason is related to scoping:
in my lang (which uses prototype oo for a global scope), if a variable is
not declared visibly, it could still have been declared elsewhere (in some
other reachable scope), thus the compiler/vm has to pretend like the
variable exists. this has a consequence of adding implicit binding,
counter-intuitively enough, in the object scope.

void foo() { x=3; y=4; }
foo();
println(x " " y); //prints 3 4

don't even need to declare x or y.


however, all this (semantic issues, among some other
implementation/performance concerns) doesn't sit that well with me...

however, I have much worse objections about the merit of using lexical scope
for the toplevel (which is why I didn't do it that way to begin with). in
particular: makes a mess of seperate, static compilation; makes things like
transferring code/objects over network connections particularly problematic;
....


so, what does this leave:
eventually, I may have to (at least as far as the compiler is concerned, but
likely also the vm as well) implement some kind of module system.

now, the difference between modules and a lexical toplevel (wrt semantics)
are subtle, but still exist.
now, the main difference will be one of needing to import things.


I am deciding between a 1 or 2 level system (modules, or packages and
modules), or an n-ary system (modules may be nested). actually, since the
implementation is still likely to be based on prototype objects (which does
arbitrary nesting), there is nothing really stopping me from doing a nested
system, which has cool features (avoiding name collisions), however, this
could just as easily be done by a naming convention, and would complicate
seperate compilation (since if each module uses a local name, rather than a
path, it is unclear how they are nested).

so, modules could all be named with a full path (eg 'system.math' or
'system.io'), then part of the nesting glory is lost (in particular, moving
modules requires renaming them), or they could be generated from the file
path (like in java), but this implies that the vm has a VFS-style system
(either internally or at its immediate disposal).

and, all this is necissarily more complicated than the current system.

it is a tradeoff I guess...


is it to be a lang suitible for little more than small scripts and primarily
under the control of the host app, or something more under control of the
vm, and more likely scalable to full-fledged apps.

since a VFS system may-well be needed for file IO anyways, it could make
sense to implement one. this would imply that the host app provide a wrapper
to allow interaction with whatever (true or virtual) filesystem mechanism it
uses.

or such...


> Regards,
>
> Bob
>
> ---
> A good traveler has no fixed plans, and is not intend on arriving.
> -- Lao Tze
>
>

"Robbert Haarman" <comp.lang.misc@inglorion.net> wrote in message
news:20061022224124.GL18480@morgenes.shire.sytes.n et...
> On Fri, Oct 20, 2006 at 03:22:26AM -0700, Avatar wrote:
>
>> 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?
>
> Well, I don't see why you would want variable declarations to be
> implicit. Explicitly declaring variables eliminates the possibility for
> confusion about scope (is this an assignment to a variable from an outer
> scope, or the introduction of a new variable?) and doesn't have to cost
> you anything extra (in terms of tokens or characters that you need to
> type).
>

yes, I will agree here.

actually, in my lang, I intend to require definitions in all cases,
eventually.

right now, however, they are only required in some cases.
part of the reason is related to scoping:
in my lang (which uses prototype oo for a global scope), if a variable is
not declared visibly, it could still have been declared elsewhere (in some
other reachable scope), thus the compiler/vm has to pretend like the
variable exists. this has a consequence of adding implicit binding,
counter-intuitively enough, in the object scope.

void foo() { x=3; y=4; }
foo();
println(x " " y); //prints 3 4

don't even need to declare x or y.


however, all this (semantic issues, among some other
implementation/performance concerns) doesn't sit that well with me...

however, I have much worse objections about the merit of using lexical scope
for the toplevel (which is why I didn't do it that way to begin with). in
particular: makes a mess of seperate, static compilation; makes things like
transferring code/objects over network connections particularly problematic;
....


so, what does this leave:
eventually, I may have to (at least as far as the compiler is concerned, but
likely also the vm as well) implement some kind of module system.

now, the difference between modules and a lexical toplevel (wrt semantics)
are subtle, but still exist.
now, the main difference will be one of needing to import things.


I am deciding between a 1 or 2 level system (modules, or packages and
modules), or an n-ary system (modules may be nested). actually, since the
implementation is still likely to be based on prototype objects (which does
arbitrary nesting), there is nothing really stopping me from doing a nested
system, which has cool features (avoiding name collisions), however, this
could just as easily be done by a naming convention, and would complicate
seperate compilation (since if each module uses a local name, rather than a
path, it is unclear how they are nested).

so, modules could all be named with a full path (eg 'system.math' or
'system.io'), then part of the nesting glory is lost (in particular, moving
modules requires renaming them), or they could be generated from the file
path (like in java), but this implies that the vm has a VFS-style system
(either internally or at its immediate disposal).

and, all this is necissarily more complicated than the current system.

it is a tradeoff I guess...


is it to be a lang suitible for little more than small scripts and primarily
under the control of the host app, or something more under control of the
vm, and more likely scalable to full-fledged apps.

since a VFS system may-well be needed for file IO anyways, it could make
sense to implement one. this would imply that the host app provide a wrapper
to allow interaction with whatever (true or virtual) filesystem mechanism it
uses.

or such...


> Regards,
>
> Bob
>
> ---
> A good traveler has no fixed plans, and is not intend on arriving.
> -- Lao Tze
>
>