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

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

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: Daniel L Speyer <dspeyer@xxxxxxxxxxx>
Cc: Reinier Post <rp@xxxxxxxxxx>, Freeciv developers <freeciv-dev@xxxxxxxxxxx>
Subject: [Freeciv-Dev] Re: commandline syntax and semantics (was: Server/ruleset unification)
From: Daniel Sjölie <deepone@xxxxxxxxxx>
Date: Mon, 5 Nov 2001 16:00:45 +0100

On 2001-11-05 09:25:40, 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...
> > 
> 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 might propose these commands
> //These 4 exist
> with
> create
> set
> destroy
> //These don't yet
> rename
> show
> forall
> if
> less
> lambda
> include
> 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, 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.  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.

I still think that no scripting functionality should be included here
but only database management (ala sql) functions... Note that
where-statements should be able to cover the same ground as if and

But I acknowledge that I don't really have much say as long as you're
the one producing the code... :) I might give my way a quick try but
unless it turns out to work out really well with little effort :) I
probably won't produce anything useful... :)

> One additional thought: should we have some sort of arithmetic commands?

Well, why not... And boolean operators...


Now take a deep breath, smile and don't take life so seriously... :)

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