Firstly - in this case, without knowing more about your problem, you
might actually get better results if you don't try and restrict your
types like this and actually allow 'or' and 'and' to accept an 'if'
and ensure that the 'if' will return something that can be interpreted
by the 'or' and 'and' - even if the 'if' just passes through it's
boolean check, or returns whether the first or second path was taken.
It may look weird, but the extra flexibility may result in a better
Now, if you do want to proceed with the type restrictions, then what
you're looking for is 'set' types. The only thing I'm confused about
is whether you actually do allow your 'if' node to take another 'if'
as it's first parameter. I had assumed that your 'if' node would not
be returning anything as you don't want it used in your 'and' and 'or'
nodes and I had also assumed that the first parameter of your 'if'
node was a 'boolean' check... but anyway, I'll lay out the problem
exactly as you specified:
gp.type.a.0.name = void-sort-of
gp.type.a.1.name = boolean
gp.type.a.size = 2
gp.type.s.0.name = boolean-and-void
gp.type.s.0.size = 2
gp.type.s.0.member.0 = void-sort-of
gp.type.s.0.member.1 = boolean
gp.type.s.size = 1
gp.nc.0 = ec.gp.GPNodeConstraints
gp.nc.0.name = if-constraint
gp.nc.0.returns = void-sort-of
gp.nc.0.size = 3
gp.nc.0.child.0 = boolean-and-void
gp.nc.0.child.1 = boolean-and-void
gp.nc.0.child.2 = boolean-and-void
gp.nc.1 = ec.gp.GPNodeConstraints
gp.nc.1.name = boolean-constraint
gp.nc.1.returns = boolean
gp.nc.1.size = 2
gp.nc.1.child.0 = boolean
gp.nc.1.child.1 = boolean
gp.nc.size = 2
Then you'd use 'if-constraint' for your 'if' node and 'boolean-
constraint' for your 'and' and 'or' nodes.
Hope that helps,
On 28/11/2008, at 1:52 AM, Eric B wrote:
> I'd like to put constraints on my nodes. I have 3 functions: 'if',
> 'and' with arity respectively 3, 2, 2. I also have 9 terminals.
> The if-function can accept ANYTHING as its parameters (including
> another if)
> while 'or' and 'and' should accept everything EXCEPT 'if'. So for
> and( or(T, T), T) is acceptable while and(if(T,T,T),or(T,T)) is not
> of the 'if' where 'T' represents a random terminal.
> If I could define 2 types: one more 'general' than the other my
> would be solved. However, as far as I know, this is not included in
> Anyone can help me? (I prefer to not mess with the Tree Builders,
> these constraints in the .params file is of course prefered)