AHLL requirements

[Pat Wendorf]

Anders Petersson wrote:

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

Ahh, so each name would have a corresponding security entry?

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

If they all mean the same, then it's not wrong, it's my fault for not knowing that.

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

Ok, so how would you explain the character picking something up?

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

Hmm... so either way it's gonna be complex.  Sounds like a challenge ;)

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

Ok then.

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

No, we all want a good game.

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

Hmm... This sounds more like Arrows ;)

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

Yep. Uniformity.

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

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

Or fun.  Most people do not wish to screw with the code to walk somewhere ;)

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

Hehe.