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

[Reinier Post <rp@xxxxxxxxxx>]

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 might propose these commands
> 
> //These 4 exist
> with
> create
> set
> destroy

'with' is not a command.

> //These don't yet
> rename

rename:  set name = ...

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

> if

'if' requires a syntax to express conditions

> less

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

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

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

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

-- 
Reinier