about and:and:and:and: and or:or:

> hi all
>
> Jannik and jb started to replace all the
>        and:and:
>        and:and:and:
>        and:and:and:and:
>        and the same for or:
>
> by they equivalent ie
>
> 1 =2 or: [ 1=3 ] or: [1=1]
> =>
> 1 =2 or: [ 1=3  or: [1=1]]
>
> the new compiler optimize both while the old one not.
> So now I would like to see what do you think.
>
> Personnally I do not like and:and:and: and more
> Now for and:and: I'm hesitating.

> hi all
>
> Jannik and jb started to replace all the
>        and:and:
>        and:and:and:
>        and:and:and:and:
>        and the same for or:
>
> by they equivalent ie
>
> 1 =2 or: [ 1=3 ] or: [1=1]
> =>
> 1 =2 or: [ 1=3  or: [1=1]]
>
> the new compiler optimize both while the old one not.
> So now I would like to see what do you think.
>
> Personnally I do not like and:and:and: and more
> Now for and:and: I'm hesitating.
>

> 2010/2/11 Stéphane Ducasse <[hidden email]>:
>> hi all
>>
>> Jannik and jb started to replace all the
>>        and:and:
>>        and:and:and:
>>        and:and:and:and:
>>        and the same for or:
>>
>> by they equivalent ie
>>
>> 1 =2 or: [ 1=3 ] or: [1=1]
>> =>
>> 1 =2 or: [ 1=3  or: [1=1]]
>>
>> the new compiler optimize both while the old one not.
>> So now I would like to see what do you think.
>>
>> Personnally I do not like and:and:and: and more
>> Now for and:and: I'm hesitating.
>>
>
> IMO, the only value was for legibility.
> But most time, I find nested code as readable.
> Sure we could also optimize all kind of alternate forms...
> But I'm not sure if it is a good idea to multiply compiler hacks...
>
> Nicolas
>
>> Stef
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project