Gecode/R - Request for syntax feedback

[Andreas Launila]

Our current pattern is:

constrain function(...).predicate(...)

First of all, can't function() always return the needed proxy object,
without an need to wrap? Or is the issue when we don't use the function()?

Yes, wrapping was to use

constrain variable.relation(arguments)

consistently for everything (the examples for that are under the header
"Proxy objects").

If we want to get rid of the need to wrap, we need to eliminate the
calls on random objects. That's not so bad, because we really want or
constraint builders worrying about the details for us.

Maybe the issue is that I led us down the wrong path with my RSpec
suggestions. What if we tried something more like Test::Unit's
assertions. I'm now thinking of a pattern like:

constrain_...(args, hash_style_options)

Translating the examples I come up with:

constrain_equal x, y
constrain_not_equal x, y
constrain_in x, enum
constrain_not_in x, enum
constrain_same enum
constrain_distinct enum

The operators are a little clumsier. We could do constrain_less_than(),
constrain_greater_than(), etc. This might be a better option though:

constrain_relationship x, :>, y

The symbol could be replaced with the other logical comparisons as needed.

For things like sorted(), I'm wondering if we could add that as an option:

constrain_equal enum, other_enum, :sorted => true

What do we think about this direction, on the whole?

I have added that syntax to the examples to get a feel for it:
http://gecoder.lokorin.org/dev/wiki/Syntax_test#constrain_.2A_arguments

It's a bit bulkier at times, but is probably more conventional (possibly
easier to get to grips with?). My primary concern with it is probably
things like sort constraints where it isn't necessarily immediately
clear which of the enumerables that will be sorted (i.e. it forces one
to look into the API documentation). Those constraints can probably be
eliminated/mitigated with some other choice of words or option names
though. I will see what it leads to.

 

[James Edward Gray II]

I have added that syntax to the examples to get a feel for it:
http://gecoder.lokorin.org/dev/wiki/Syntax_test#constrain_.
2A_arguments

It's a bit bulkier at times, but is probably more conventional
(possibly
easier to get to grips with?).

I agree that it lacks the sex appeal of the RSpec approach. However,
it does allow us to avoid wrapping all variables and core class
hacking, which I consider big wins. I would be willing to pay the
price.

James Edward Gray II

 

[Andreas Launila]

I agree that it lacks the sex appeal of the RSpec approach. However, it
does allow us to avoid wrapping all variables and core class hacking,
which I consider big wins. I would be willing to pay the price.

I'm not really sure that the cost compared to the others is that much
lower. The following are the changes necessary to make the others work
as far as I'm aware, please correct me if I'm missing something.

* Custom enums with variables have to be wrapped before use (arrays and
matrices created through the convenience methods are wrapped there).
* It becomes harder to create temporary arrays of variables, e.g. [x,y].
Instead the user has to use variable([x,y]) or something similar (or
possibly IntVar.array(x,y) if that's better).

Beyond that I can not see anything that requires wrapping or altering
core classes (or any other non-gecode classes for that matter).

What I see as a bigger problem of must/must_not is where to fit the
constraint options. It might be necessary to change it around a bit to

variable.<must|must_not> relation(argument)

or something similar for that to work.

 

[James Edward Gray II]

I agree that it lacks the sex appeal of the RSpec approach.
However, it
does allow us to avoid wrapping all variables and core class hacking,
which I consider big wins. I would be willing to pay the price.

I'm not really sure that the cost compared to the others is that much
lower. The following are the changes necessary to make the others work
as far as I'm aware, please correct me if I'm missing something.

* Custom enums with variables have to be wrapped before use (arrays
and
matrices created through the convenience methods are wrapped there).
* It becomes harder to create temporary arrays of variables, e.g.
[x,y].
Instead the user has to use variable([x,y]) or something similar (or
possibly IntVar.array(x,y) if that's better).

Beyond that I can not see anything that requires wrapping or altering
core classes (or any other non-gecode classes for that matter).

You are probably right.

If we go with the wrapping approach, I just think the most important
thing is to make sure we are careful to support custom data
structures as painlessly as possible.

James Edward Gray II