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

[Reinier Post <rp@xxxxxxxxxx>]

On Sat, Sep 29, 2001 at 02:55:03PM -0700, Arien Malec wrote:
> 
> --- Reinier Post <rp@xxxxxxxxxx> wrote:
> > 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
> 
> Since the first object is to unify ruleset and command line syntax, we don't
> need to do anything except for the case insensitive indentifer, IMHO.  Later,
> when we want to unify savegames, etc. it  may be necessary to make it more
> complex. But I'd recommend keeping it really simple for the moment.

Yes, at first, identifying objects by prefixes of their .name values,
and not hving to indicate anything else, only needs to work for players,
which is the existing case.  I was trying to see if this will generalise.

> > 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.
> 
> Rulesets & command-line syntax don't need to worry about cities. Savegames
> will, but this is a later stage. So I think we can assume that every object 
> can
> have a case insensitive identifier, and we don't need to worry about numerical
> indexes.

Yes, assuming "clean" savegames (producible by civclient/civserver).

> > 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].
> 
> Having all sorts of aliases for the same object definitely complicates the
> parsing.

It's not really a question of "all sorts of aliases" but

 + to what extent you want to be able to support the actual data structure
 + to what extent you want to be able to abbreviate paths to elements
   within that structure


>If the first component of the name (e.g., tech.greek.... or
> tech[greek]....) lets us dispatch the right handler, the toplevel parsing code
> can be really really simple. If it has to realize that game.nation.english is
> the same as game.player.liz.nation is the same as player.liz.nation is the 
> same
> as nation.english ....

This is not something you want to re-code, if it can't be
generated from the existing code it must not be done at all.

> > 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
> 
> I'd avoid letting other objects be on the right hand side for the moment. The
> current command line and rulesets don't allow it. After we get that done, we
> can make it more complicated.

Good plan, but I bring this up because decisions on syntax you make now
will influence how you can extend it later.

> > 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.
> 
> I don't understand this? If I issue:
> 
> set tech.railroad.name "Railroad"
> 
> And the railroad tech doesn't exist, should it be automatically created? 
> That's
> going to lead to lots of bad objects due to typos, IMO.

Yes, I think so, too.  My idea was that with 'set' you never create
an object that you forget to link into the data structure, because the
'set' specifies where it must be linked in.  But that isn't true:
when I say

  create tech windmill name="Windmill"

the 'windmill' is added to the list of techs, which in my syntax would be.

  set techs.next.name "Windmill" 

> Better to issue a create first:
> 
> create tech.railroad
> set tech.railroad.name "Railroad"

I cannot see what 'tech.railroad' would mean in the first line.
In my proposal it is the tech whose .name field matches /^railroad/i,
but the name is only assigned in the second line.

> Arien

-- 
Reinier