Home » forums » LtU Forum

Semantics of the dodo language

This page introduces the semantics of the dodo language, as I imagine them.
http://dodo.sourceforge.net/semantics.html

It is not complete and I will continue to add to it. But this should be enough to start a discussion.

Small quote:

An object is a structure variable which has a hidden attribute Class which refers to its interface. This interface is used to access attributes and call member functions of the variable, without a need for the caller to know the exact type of the variable.
Example:

object1.draw(paper)

A class is a type associated with an object instance.

By Denis Bredelet -jido at 2012-08-07 22:47 | LtU Forum | previous forum topic | next forum topic | other blogs | 4360 reads

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Had a brief read through; it

Had a brief read through; it seems straightforward enough, although "structures" seem to be used an awful lot for a language with objects ;)

You may be interested in Ian Piumarta's "Id" object model, which uses a simple mechanism (subtracting 1 from pointers) to make an "everything is an object" framework http://piumarta.com/software/id-objmodel/

He's also generalised the idea to "memory offsets with defaults". For example, in a prototype object model the methods are either present at a particular memory location, or they default to the parent (which can default to its parent, etc.). Likewise with namespaces/scope, a symbol is either present in the current namespace or else it defaults to its enclosing scope (which can default to its enclosing scope, etc.) http://www.vpri.org/pdf/tr2011003_abmdb.pdf

By Chris Warburton at Wed, 2012-08-08 08:22 | login or register to post comments

Re: Had a brief read through;

I appreciate the feedback.

My structures are more like objects which lack polymorphism since they have associated operations. I consider polymorphism as an overhead which should only be used if it brings some advantage.

Ian's paper seems to focus on efficiently retrieve fields at different levels of overloading. An alternative to the fallback mechanism, of course, is to copy the original values at lower levels in the hierarchy. This is supposing there are no updates to propagate, which I believe to be the case in dodo.

By Denis Bredelet -jido at Wed, 2012-08-08 17:00 | login or register to post comments

Symbol lookup in scope

Likewise with namespaces/scope, a symbol is either present in the current namespace or else it defaults to its enclosing scope (which can default to its enclosing scope, etc.)
http://www.vpri.org/pdf/tr2011003_abmdb.pdf

Ah I missed that part. Yes, it could be useful for symbol lookup in a scope - but this may be resolvable at compile time and I am not sure the runtime would need a hash map at all.

In fact the paper mentions that the same symbol could be stored several times for different levels, what is the use of storing a shadowed variable? I must have missed something.

By Denis Bredelet -jido at Wed, 2012-08-08 17:17 | login or register to post comments

Yes, it could be useful for

Yes, it could be useful for symbol lookup in a scope - but this may be resolvable at compile time and I am not sure the runtime would need a hash map at all.

From what I can tell, Ian prefers the bind-as-late-as-you-can approach. This is much less efficient for CPU-time, hence his assumption of a hardware implementation. A telling quote is this:

In the absence of hardware,
the approach presented in this paper could still be valuable
as a means to present and compare dynamic behaviours, or
as a concise notation for dynamic mechanisms to be com-
piled and run on stock architectures as part of the language
runtime support library.

As for your second point, I can't see what your referring to I'm afraid. There is mention of garbage-collection issues, including an unanswered question about spotting constant redirections (ie. references which will always get redirected to the same location)

By Chris Warburton at Thu, 2012-08-09 08:46 | login or register to post comments

I can't see what you're referring to

I am referring to this:

Each additional key position (gained by increasing n by 1, for example) creates a new “dimension” or “taxonomic space” in which any number of new taxonomies can be created. These new taxonomies will all be orthogonal to (and completely independent from) those in other key positions (even if they share the same concrete keys).

If the dictionary entries are added and removed when entering and exiting a scope, this could be useful - a single hash map is needed.

By Denis Bredelet -jido at Thu, 2012-08-09 12:18 | login or register to post comments

Updates: added Abstract State, Macro, Constructor

Updates: added Abstract state, Macro and Constructor.

The link is still the same -
http://dodo.sourceforge.net/semantics.html

By Denis Bredelet -jido at Sat, 2012-08-11 19:49 | login or register to post comments