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

[Daniel L Speyer <dspeyer@xxxxxxxxxxx>]

On Mon, 5 Nov 2001, Reinier Post wrote:

> On Mon, Nov 05, 2001 at 09:25:40AM -0500, Daniel L Speyer wrote:
> > On Mon, 5 Nov 2001, [iso-8859-1] Daniel Sjölie wrote:
> > > On 2001-11-05 11:27:22, Reinier Post wrote:
> >      [...ommissions...]
> > > > If you want to pick an existing language to use, I'd use a Perl subset.
> > > 
> > > Well, obviously we don't have the same "vision" for this language... :)
> > > I don't want a scripting language here but a database management
> > > language... A language to manage the database that all the techs,
> > > players, buildings, units and so on in freeciv are...
> > > 
> > > Sure, scripting might be nice somewhere but I think it'd be preferable
> > > to separate that problem from that of managing the data...
> 
> Call me dense, but I don't see the difference.  Can you explain?
> 
> > I agree that the format should be kept fairly simple, but
> > extendable-in-self seems like a good idea, and that means including the
> > most fundamental scripting constructs in the language itself.  I think
> > orthogonality would be a good thing, here (sorry Reiner), but if a
> > language has no underlying branching and looping there's almost no way to
> > stick those on top of it.  
> 
> I don't understand what you mean to say here.

I'm proposing that we code in C the minimum nessesary to define everything
else in config files.  That means we need branching and looping because
those are pretty fundamental (try implementing 'if' in terms of more
primitive operators), but I think we *don't* want a PERLish philosophy
(you proposed using a perl subset earlier, IIRC) of
implement-everything-potentially-useful-as-a-built-in-function.

> 
> > I might propose these commands
> > 
> > //These 4 exist
> > with
> > create
> > set
> > destroy
> 
> 'with' is not a command.

It is the way I've implemented it.  I suppose you could argue that it's
conceptually different, but it takes a namespace and a block of code to
run within that namespace (e.g. with units.archers {set attack 3;set
defend 2;} )

> 
> > //These don't yet
> > rename
> 
> rename:  set name = ...

I really think non-member tags are a better idea.  The displayed names for
units can contain spaces or periods.  Consider:

create units.littledoctor {set name "M.D. Device";} #Makes the game boring

Now, during the game, it should show up as "M.D. Device", but it would be
very awkward to refer to it as that in configuration.

> 
> > show
> 
> I'm assuming this will exist.
> 
> > forall
> 
> This is the interesting one: it introduces an identifier.
> Without 'forall' you can technically do without them.
> I would remove 'with' when 'forall' is present:
> 
>   forall cities c {
>     # do something with the city c
>   }

This can be done like the with command, just stick each whatever as the
root namespace.  Consider:

forall units {
        set vision 3;
}

> 
> > if
> 
> 'if' requires a syntax to express conditions

Yes, and this is unfortunate.  This is why I proposed the less command
(from which all the standard test could be written).  It would be most
useful with forall, e.g.

forall units {
        if {less hitpoints 15} {
                set vision 3;
        }
}

Of course, some sort of configuration-defined where statement could
simplify this for most end-users.

> 
> > less
> 
> Is this '<' ?  You also need something like '==', and logical operators.

All those are derivable, at least granted some mechanism for returning a
value.

> 
> > lambda
> 
> While function definition would be nice, I have the same issue with
> them as with variables: it seems better to place these definitions
> within the game structure itself than in a separate namespace.
> I.e. I'd use object method definitions instead.
> That way the definitions would be saved with savegames, for example.
> It would also solve the naming of object attributes within functions.
> Now the next thing you want is method inheritance ...

I don't see where we'd use real OOP; maybe I'm missing something.  It
seems to me that the main need for functions is to shield lusers from the
bareness of the command set.  I'm not set on using lambda syntax,
especially since it requires local variables (maybe there's a way around
that), but I can't see how anything we use would be that different.

> 
> It's not clear to me whether there is a good point to stop and say:
> this is all we need to implement rulesets.
> 
> If we eventually want the language to be this fancy, it may be better
> to just interface with an existing language.  Perhaps forall and if
> are already too much.
> 
> > include
> 
> 'include' already exists, it's called 'read'.
> 
> > These should be enough to allow everything else we'd want to be
> > implemented in them, maybe in the same file that contains default
> > configuration.
> 
> Yes.
> 
> > Yes, some of this looks a bit Lispy, but if we're staying with 
> > command [args...]
> > (and I think we should) then we're going to be Lispy no matter what.
> 
> As long as the syntax isn't Lispy ...

Well, I don't think we should have foo and (foo) (or even foo and
{foo}) mean different things, but we're pretty prefix so I think we're
bound to be that Lispy.

> 
> > The
> > complexity of the if and lambda commands will only be of interest to
> > extenders anyway -- the average user will only touch the first five
> > commands.
> > 
> > One additional thought: should we have some sort of arithmetic commands?
> 
> Are they required for rulesets?
> "Make this unit type 1 stronger than the strongest existing one"??
> 

I would think of something like:

read middle-earth
forall units {
        multiply vision 2
        add move 1
}

--Daniel Speyer
"May the /src be with you, always"


> -- 
> Reinier
> 
>