Gavin Sinclair wrote:

>Zach wrote:
>  
>
>>This has been a very fun discussion. I'll shut up now unless anyone
>>comes up with good reasoning for '..' and '...' or until Matz speaks. I
>>think everyone knows where I stand.
>>    
>>
>
>I'll try to come up with a good reasoning.  Pretend I'm designing a language.
>
>x..y is known to programmers of some other languages as representing a
>"range"  (i.e. not necessarily what we'd call a Range, but something close
>to the concept).  I decide that this concept will have its own
>representation as a Range object.  So:
>
>  2..6        # -> Range object
>
>So far so good.  And familiar to some, but by no means all, programmers of
>other languages.
>  
>
Yes I agree with you here. This is how languages have been developed it 
appears with the Range operator in mind.  At this point the idea for an 
exclusive range operator has not came to mind yet. So why would you even 
consider '..' vs '...', at this point? You wouldn't.

>Now I decide, for the good reasons put forth by others, that end-exlusive
>ranges are useful enough to be treated explicitly as well.  I go hunting
>for a way to represent them, and settle on
>
>  2...6       # -> Range object
>
>I find something visually appealing about it, don't agonise over it too
>much, and there you go -- it's in the language.
>  
>
If you design a language in the two steps you just provided then i agree 
with you.  But having 20/20 hindsight what would have made more sense 
when designing an inclusive and an exclusive range operators? What seems 
more natural? Try to not include the reasoning "because that's how it 
is" or "because that's what most people know".

>Speaking as a Ruby programmer again, I personally find nothing whatsoever
>confusing about the literal range notation, inclusive or exclusive.  
>
I agree with you here as well. As a ruby programmer you know how they 
work so there is no need to change them.  Now envision that there is 
someone you are teaching Ruby, and at the same time you are teaching 
them how to program. What makes more sense when describing the .. and 
... operators? Again, try not to include "because that's how it is" or 
"because that's what people know". Try to keep it natural and making sense.

>And I
>dislike the thought of reversing the notations; not based on precedent and
>not wanting to change things, but based an aesthetics.
>
Where is the aesthetics in the reasoning for .. and ... ? I see no 
beauty. I see nothing that makes sense. I see something that is done a 
certain way because that is how it was done before. Does this make it 
the correct way to do things? Try to think about this from a scientific 
view point when designing a language. Noting ahead of time you want 
inclusive and exclusive range operators. Your goal for the language is 
simplicity, elegance and to make it seem natural for the programmer. 
What would you use to represent those operators and why? What logically 
makes sense? Share your reasoning. Try to do this without using the 
current implementation(s) in mind. Pretend you are designing your 
language from scratch, or that you are developing a version that doesn't 
need backwards compatibility. What is your conclusion and how did you 
achieve it?

If you can answer those and come to a conclusion that the current 
implementatoin makes the most sense for the elegance and natural feel 
for your language, then I would love to hear your reasoning. Perhaps you 
will convince me to change my view. As of yet, I haven't heard a reason.


>  And trying to
>explain why is like trying to explain appreciation for a poem.
>  
>
If this were an actual language debate you would have just lost. You 
didn't show any logical reasoning or rational conclusions to support 
your position. This is like Larry Wall saying that Perl is the best 
programming language syntacically because it is like a overly complex 
Haiku and it just cannot be explained because of it's aesthetics.

Zach