On Jun 7, 2007, at 9:10 AM, Andreas Launila wrote:

> James Edward Gray II wrote:
>> On Jun 6, 2007, at 5:21 AM, Andreas Launila wrote:
>>
>>> James Edward Gray II wrote:
>>>> On Jun 5, 2007, at 2:43 PM, Andreas Launila wrote:
>>>>
>>>>> == Issues ==
>>>>>
>>>>> === Describing (linear) constraints ===
>>>>
>>>>> A problem with the above is that people might look at it and
>>>>> instinctively think that it's something that does not have a side
>>>>> effect. Therefore prepending some sort of method might convey that
>>>>> intention better. For instance we could allow people to write the
>>>>> following.
>>>>>
>>>>> constrain x + y == z
>>>>
>>>> RSpec works a lot like this.  It has you define expectations  
>>>> with syntax
>>>> like:
>>>>
>>>>   some_obj.should     equal(whatever)
>>>>   some_obj.should_not equal(whatever)
>>>>
>>>>> Fitting words other than "constrain" might be "assert", "post" and
>>>>> "add".
>>>>
>>>> I like the word "constrain."  If you go the RSpec route though,  
>>>> you will
>>>> probably also want a negative form and I don't know what that  
>>>> would be.
>>>>
>>>
>>> That would be a nice solution. The best word I can think of for
>>> "constrain" is "constrain_negation", which is probably far from  
>>> perfect.
>>>
>>> constrain_negation x + y == z
>>
>> Yuck.  And I mean that in the nicest possible way.  ;)
>>
>>> Another variation would be to use a combination of constrain and  
>>> RSpec's
>>> should/should_not.
>>>
>>> constrain (x + y).must == z
>>> constrain (x + y).must_not == z
>>
>> That's not too bad.  I think my biggest complaint there is that it  
>> makes
>> the flow of the line a little hard to follow.  Perhaps must/must_not
>> could replace constrain altogether though:
>>
>> must     x + y == z
>> must_not x + y == z
>>
>> That doesn't read too well though, does it?
>>
>
> I think that must/must_not would make a fairly interesting syntax  
> in the
> sense that it reads very well. Therefore I have tried some examples at
> http://gecoder.lokorin.org/dev/wiki/Syntax_test#must.2Fmust_not .
>
> They probably require skipping "constrain" though and replacing it  
> with
> something block-like, it just doesn't read right otherwise.

I like how this reads in the early examples and worry about that  
amount of core hacking we have to do to support the later examples:

   whatever.with_offsets   ...
   whatever.sorted         ...
   whatever.sorted_with    ...
   whatever.occurrences_of ...
   whatever.any            ...
   whatever.all            ...
   whatever.implies        ...
   whatever.equivalent_to  ...

James Edward Gray II