[Freeciv-Dev] Re: commandline syntax and semantics (was: Server/ruleset unification)

[Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx>]

On Fri, Sep 28, 2001 at 09:35:18PM +0200, Reinier Post wrote:
> 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

This may be a bit to much for the first version. The first version
should have the same power as the current code. You can program code
to understand various short cuts later.

> 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

Do we really need such constructs? I agree that there are some
problems if such powerful constructs are introduced.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "We've all heard that a million monkeys banging on a million typewriters
  will eventually reproduce the entire works of Shakespeare.
  Now, thanks to the Internet, we know this is not true."