From: James Edward Gray II <james@...>
Date: 2007-06-07T23:06:56+09:00
Subject: Re: Gecode/R - Request for syntax feedback

On Jun 7, 2007, at 8:35 AM, Andreas Launila wrote:

> James Edward Gray II wrote:
>> On Jun 7, 2007, at 3:58 AM, Andreas Launila wrote:
>>
>>> Andreas Launila wrote:
>>>> James Edward Gray II wrote:
>>>>> On Jun 6, 2007, at 12:35 PM, Andreas Launila wrote:
>>>>>> Something more on the form of the rest of the syntax
>>>>>> would probably be
>>>>>>
>>>>>> constrain element(array, x).equal(y)
>>>>>>
>>>>>> It just doesn't read as well to me. Maybe there's a better way of
>>>>>> representing constraints where the function has to take multiple
>>>>>> arguments, such as returning an helper with only one method,  
>>>>>> i.e. as
>>>>>> follows.
>>>>>>
>>>>>> constrain element(x).in(array).equal(y)
>>>>> I would say avoiding core class modification is important.  If  
>>>>> that
>>>>> means we need element(), that's probably just a price we need to
>>>>> pay, in
>>>>> my opinion.
>>>>>
>>>>> See my earlier comment about proxy objects for another option  
>>>>> though.
>>>>>
>>>>
>>>> I will write up some similar syntax examples with proxy objects  
>>>> to see
>>>> how big the difference is.
>>>>
>>>
>>> Examples: http://gecoder.lokorin.org/dev/wiki/ 
>>> Syntax_test#Proxy_objects
>>
>> That page talks about how we loose some convenience in that we  
>> need to
>> now wrap simple IntVars.  I'm not sure that's 100% necessary  
>> though.  If
>> we built the class, we should be able to count on it having what we
>> need.  The wrapper could just be for Enumerables and/or custom data
>> structures, I think.  Double-check my logic there though.
>>
>
> Your conclusion is correct. But my intent with the text is that we  
> have
> to wrap enumerables before use, I'm not sure how to reach the other
> interpretation.

Oh yes, I misread.  Sorry.

I'm not giddy with the idea either.  Maybe we're getting too  
complicated here.  Let's back up.

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()?

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?

James Edward Gray II