AHLL requirements

[Pat Wendorf]

Anders Petersson wrote:

> Requirements for AHLL to do it's job (in no particular order):
>
> * Must be a HLL
> Low-level issues such as memory managment is not relevant inside the game,
> and could even threaten the security of the server. There's more arguments,
> I guess, but I don't think I have to convince anybody on this point.

> * Access to types as objects
> For the ability to handle whole aspects, generalize things to eg. dimensions.

> * Security thru "positive access grantings"
> You can't access what isn't explicitly granted you. Partly same reason as
> previous item, partly to enforce a security police (the only thinkable, I
> believe).

So each object will have a security list?

> * A handle to an object is necessary to do anything with it
> To create some kind of "physical barrier", plus security. (You can't reach
> for something in the other corner of the world)

You'll have to explain this one better.  What is a handle, and how do you get
one.

> * Safe pointers
> 'Pointers' to make it possible to reference existing objects (like what
> places are connected to each other), 'safe' to avoid user-caused bugs.
>
> * Nested objects
> To enable compound data types. (Like a place or a physical 'thing' with
> attributes like weight, etc.)

Hmm.. this sounds like it gives flexibility, but adds some complexity.  Is it not
possible to just have lots of types of objects?

> * Typed language
> To enforce necessary restrictions. Without this, more or less anything
> would be possible and the world would collapse to a soup of elementary
> particles, so to speak.

So the language would need some strict definitions?  I think I like that idea.

> * Represent code as data, and have a way to execute the same
> This is necessary to enable code to exist inside the system, to at all
> enable any wider flexibility.

Hmm... again adding complexity I think.  Game != OS ;)  Code can exist within the
system in a database of events and such.  For example if a character walks into
an area that is "trapped" then, the trap code can be referenced.  No need to
store the code along with the trap I think.

> * A way to "simulate" objects, and control them from the outside
> Instances of basic data types (eg. integers) ought not be represented
> inside the system (imagine 2^32 integer objects...). To do the same with
> elementary functions is impossible. In addition, events must have a way to
> flow between the game and the users.

You lost me here.

> * Visible namespaces
> To let players see their choices, generally seen. (This is on a low level.
> For example, there must be a way to see what one is carrying.)

I'm not sure why it would be called visible namespaces.  I think the way a
character would see what he is carrying would be a piece of code that lists the
contents of the .holding property of the character or something similar.  This
would be more a function of the client than the server I think.

> * Persistant objects
> Obvious reasons; who'd like the world to disappear when you turn away?

Yeah, that's kinda important ;)

> * Object cloning
> If types are objects, you simply *need* cloning to instantiate objects.

I think so also.

> This is what I've come up with so far. There are probably more items to add.

> Let's hear what we can agree about these very basic requirements. If our
> opinions differ much on this, there's more than the language on stake; this
> is about the AKOS vision.

Hmm... this seems like an incredibly flexible in game system.  I'm just wondering
if it's not duplicated effort.  I know some languages such as Lisp and smalltalk,
and to a lesser degree, even python could fit these requirements.  And each one
can be embedded in a nice low level C++ program.

I'm not saying a *new* HLL is not possible, but just more difficult.  Frankly, I
think your vision is to be applauded in it's scope.  You're reaching for the
stars again, and the added flexibility that this system would bring could extend
it's life greatly (yes I've heard games have definite life spans).  However our
life span is limited ;)  If you can create this beast of a language in the next
couple of months, it may have more use than just a game engine.  I guess the
decision will be up to the people who wish to do the work.  I don't believe I
have theknowledge or experience to make a new language, so I may not be of much
help in this end of the project.

- Beholder