Complete.Org: Mailing Lists: Archives: freeciv-dev: September 2001:
[Freeciv-Dev] commandline syntax and semantics (was: Server/ruleset unif
Home

[Freeciv-Dev] commandline syntax and semantics (was: Server/ruleset unif

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: freeciv-dev@xxxxxxxxxxx (Freeciv developers)
Subject: [Freeciv-Dev] commandline syntax and semantics (was: Server/ruleset unification)
From: Reinier Post <rp@xxxxxxxxxx>
Date: Fri, 28 Sep 2001 21:35:18 +0200

On Fri, Sep 28, 2001 at 09:42:14AM -0700, Arien Malec wrote:
> 
> --- Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
> > > simple_set_statement is intended for 
> > 
> > > toplevel attributes:
> > 
> > And that is the point. What makes such attributes toplevel attributes? 
> > Why can't "huts" be under a "map" object? Why can't "ailevel hard" be
> > under "aicontroll"? Why can't "min_dist_bw_cities" in another category
> > (event if this is named "misc")? IMHO they are special because of
> > historical reasons.
> 
> The distinction I mean between "toplevel attributes" and "object attributes" 
> is
> that, regardless of whether you call ailevel "aicontrol.ailevel" or "ailevel"
> or "game.ailevel", you can treat the whole string as a unique identifier that
> identifies the one and only one ailevel variable you want to modify. However,
> for nation.greek.init_techs, you have to find the greek nation *first*, before
> you can modify it.
> 
> I would strongly recommend that if we want to use "dotted syntax" to organize
> variables, that we use a different syntax to identify objects.
> 
> e.g.
> 
> game.ailevel
> 
> vs., e.g.
> 
> nation[greek].init_techs

I don't think this is necessary, but it would obviously be less ambiguous.

To denote an object, you could use

  + field names (eg. 'ailevel', 'players')
  + the value of the 'name' field or a case-insensitive prefix (eg. 'Eliz')
  + with lists, index numbers (eg. '5')
  + with lists, syntax to denote the last and (last+1)-th element

  + rules to omit full path names in contexts where they can be derived

E.g. if the latest of 6 players to join has name "Elizabeth II" and
nation "English", you could address her player struct as

  + game.players."Elizabeth II"
  + game.players.eliz
  + game.players.5  (or 6?)
  + game.players.last  (or players.$ or something like that)
  + players.last  ('game.' is usually superfluous)
  + eliz  (only in a context where a player must be specified)

and her nation as

  + game.players.6.nation
  + nations."English"
  + eliz.nation  (this one really isn't high on the priority list)

If names are always unique within lists (city names usually are, but
not always), then using names instead of index numbers isn't
ambiguous.  If they are unique across types (eg. no ruler and city have
the same name) then using names is never ambiguous even in abbreviated
syntax.  Such ambiguity will rarely arise in practice, but it is better
to support it in order to support the use of prefixes.

When ambiguity occurs, interpretation as a number of keyword takes
priority over interpretation as name.  Eg. player.5 is player 5,
not the player named 5; player "5" is the player named 5.
(Even if you block such player names in the client,
they can be created by editing savegames.)
When ambiguity cnanot be resolved,
refuse to execute the command and give an error.

I don't think the use of . syntax for all these cases will lead to
serious problems.  It complicates syntax checking a little, but
not very much.  It may be better to require ""s around names,
and/or to use using []s around index numbers; that way you would
have game.players."5" and game.players[5].

A distinction must be made between pointers and their values
(usually objects or lists).  This is only important when a
pointer is used as the right hand side in an assignment:

  set "Dresden".worklist = "Leipzig".worklist

may mean that Dresden gets a copy of Leipzig's worklist, but
it may also mean that it gets linked to the same worklist.
I think it's best to indicate the latter case by using the command

  link "Dresden".worklist = "Leipzig".worklist

ad make 'set' always assign a value, even if the value is a struct or list.

> I'm also leaning towards the simpler set/create syntax, because it makes the
> lexting and parsing code much easier. For instance, all commands can be 
> newline
> terminated.

It does make the parsing easier, but I think it's cleaner to use
'link'/'set' instead of 'set'/'create'.  You can fill objects with
default fields in the 'set'/'link' system just as well.

> Arien

-- 
Reinier


[Prev in Thread] Current Thread [Next in Thread]