Complete.Org: Mailing Lists: Archives: freeciv-dev: April 2005:
[Freeciv-Dev] Re: (PR#12873) OR Requirements for Buildings
Home

[Freeciv-Dev] Re: (PR#12873) OR Requirements for Buildings

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
Subject: [Freeciv-Dev] Re: (PR#12873) OR Requirements for Buildings
From: "Vasco Alexandre da Silva Costa" <vasc@xxxxxxxxxxxxxx>
Date: Mon, 25 Apr 2005 05:46:21 -0700
Reply-to: bugs@xxxxxxxxxxx

<URL: http://bugs.freeciv.org/Ticket/Display.html?id=12873 >

On Sun, 24 Apr 2005, Benoit Hudson wrote:
> On Sat, Apr 23, 2005 at 09:54:31AM -0700, Jason Short wrote:
> > Vasco Alexandre da Silva Costa wrote:
> > > So an answer is: Reverse Polish Notation aka postfix notation. Like this:
> > > sreqs    =
> > >     { "type", "name", "range"
> > >       "Tech", "Electronics", "Player"
> > >       "Building", "Factory", "City"
> > >       "Operator", "AND"
>
> > Not that I'm in favor of such craziness but prefix notation would be
> > better.  Just reverse the above list and you have prefix notation.
>
> This seems like a good idea; now we can have a single effect that
> describes how a hydro/power/nuclear/hoover increases production rather
> than the current error-prone cut & paste technique, and this also makes
> it more elegant to state that bonuses don't stack.
>
> I'm not sure why it needs to be "Operator", "AND" rather than just a
> single line with the bare-word 'and.'
>
> We could have this just be 'reqs' and give it a NOT operator.
>
> More ambitiously, a syntax I could see:
>         reqs := "reqs = {" reqlist "}"
>         reqlist := reqitem reqlist | reqitem
>         reqitem := requirement | reqoperator
>         reqoperator := '(' | ')' | 'and' | 'not' | 'or'
>         requirement := ...
> then we can do:
>  reqs = { "type", "name", "range"
>            and {
>               "Tech", "Electronics", "Player"
>               "Building", "Factory", "City"
>               or {
>                 "Terrain", "Mountains", "Adjacent"
>                 "Special", "River", "Adjacent"
>               }
>               not "Terrain", "Ocean", "Adjacent"
>            }
>         }
> which means we need electronics and a factory and be near either
> mountains or river but not be on the coast (that last one just to show
> the 'not' operator).
>
> It's not unlikely that we should just use yacc (or bison) to parse this.

Right. I did not propose something like that precisely because it would
require changing the .ini parser. I have to say I am starting to agree
with Jason here though. A ruleset writer can go around the restriction
just by adding more buildings.

---
Vasco Alexandre da Silva Costa @ Instituto Superior Tecnico, Lisboa





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