AHLL requirements

[Anders Petersson]

Sorry, this became rather long.

At 1999-10-07 , you wrote:
>Anders Petersson wrote:

[snip]

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

I'm thinking of it like a separate namespace for each object, where you can 
access what you have in your namespace. Or more exactly, you can access 
what you have a reference/pointer to. The namespace list (now I'm 
stretching the definition of namespace, I know) would contain those references.

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

Ok. the triviality of the statement might be confusing. A handle is the 
same as a pointer, is the same as a reference... I use the words 
interchangably, and I apologize if that's wrong. Anyway, I simply mean that 
in order to access another object in any way, the object (the one who wants 
to access) must be able to specify the wanted object. In ordinary 
programming, the programmer just uses the variable name, and this could be 
about any of the variables available. When the system is being programmed 
run-time, things are a little different. You are not watching the object 
system from above as usual, you are seeing the world as if you yourself 
were one of the objects. You can't any longer pick any variable; you are 
limited to those your "personal object" can see.
The namespace consists of such handles. The handles of children are 
automatically available (possibly part of the namespace).
Getting a handle is nothing you can do by yourself. (This appears natural 
when considering that handles is all there is to security.) You have to be 
given a handle by someone who 1) already has the handle (possibly the 
object itself) and 2) has a handle to you. Think of it like this other 
object running a command copyHandle(hSrc, hDest) where both arguments are 
handles.

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

That would be possible, yes. What I can argue against is the level of 
complexity /that/ in turn would introduce, and how it would erode 
flexibility. We could do some reasoning around it if you like.

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

Yes, that's necessary. My most recent idea even goes further... more on 
that some other time.

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

Yes, we could do this as they use to do. Not that I know exactly how 
ordinary MUDs are designed, but it seems to be something like that.
This do add complexity, but only insignificant if the code still would have 
been interpreted. Static code (in the souce) would be much much simpler to 
do, but I don't think anyone of us would like to have the game degraded so 
much.

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

Ok. This is something I know you won't like. Everything is an object, 
including "atomic" data types like individual integers. But we don't want 
to explicitly store each integer - that would simply be impossible. 
Instead, we simulate them, by referencing to them as "the subobject of the 
'integer' object that has index 4000", to take the number 4000 as an example.
The reason to model everything in the first place is to get a 
straightforward, neat and managable implementation (with exception for the 
simulated objects).

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

In either case, it's a client-side function. I want this to behave like you 
"see" the world thru your character's object. It would be the same way for 
everybody/everything, NPCs as players as scripts. One implementation for 
all cases. Can you too see the gain in that?
In a way, you are right. The function would list those contents. But the 
contents are themselves children of .holding, so we have the problem of 
seeing children. The solution I propose is letting children have a place in 
the namespace (in some way or another) and letting objects list their 
namespaces to find out what children there are.
Your proposion is also possible, but it relies on having things "your way"; 
no subobjects/children, etc. (And it would decrease flexibility (this is 
turning into a manta :P).)

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

Agreed; the point is flexibility. However if this would be possible with 
any of these common languages is another question. Types as objects is one 
issue. Ability to change code and data run-time from the perspective and 
with the rights of individual objects is another, maybe bigger issue. The 
whole idea more or less builds on that, everybody is equal. All languages I 
know of would place you in the position of programmer, with access to 
everything (which is kinda pointless if the game is to be challenging).

It seems like I missed some of the essance of the reasons for AHLL in my 
original mail. What a blunder.

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

Nice to see that we understand each other.
I might be naive in trying something like this. That is an open question to 
myself. Still, I want to believe I'm not, and I certainly don't want to let 
this idea go now. No... not until it is obvious it would be meaningless to 
try. And I believe that once we've got the theories cleared up, the 
implementation will be in reach.

But we don't have a all-or-nothing situation because of that. You 
concentrate on the demo; no pretentious plans are needed for that. If 
everything goes well, I can tell you after a while what changes need to be 
done and we'll both be happy. Otherwise, only you will be happy. ;)

binEng