[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

Re: Range syntax theory

Mills Thomas (app1tam)

9/30/2004 3:49:00 PM

Okay, maybe we think of it this way. '..' is a club. '...' is a club, with
a bouncer at the door.

Or, '..' is a path. '...' has a marble tripping up the last entry and
pushing it off the path.

Or, '..' represents a 2-dimensions (a vector). And '...' represents two
dimensions with a daemon kicking the last entry into its own exclusion
dimension (a plane) to live forever, planely in lonely solitude.

Or, maybe I should quit now...Drew

-> -----Original Message-----
-> From: Zach Dennis [mailto:zdennis@mktec.com]
-> Sent: Thursday, September 30, 2004 9:31 AM
-> To: ruby-talk@ruby-lang.org
-> Subject: Range syntax theory
->
->
-> I have been thinking lately about rangess and I will give
-> you the two
-> different range operators and what comes to mind first.
->
-> Operator One: .. (two dots)
-> Example: 1..5
-> What comes to mind: Exclusive
-> How It Works: Inclusive (the last number 5, is included)
->
-> Operator Two: ... (three dots)
-> Example: 1...5
-> What comes to mind: Inclusive
-> How It Works: Exclusive (the last number 5, is excluded)
->
-> How range operators work seems sort of backwards to me. It
-> would appear
-> as if the "..." (three dots) would be the inclusive one,
-> including the
-> last value and the ".." (two dots) would be exclusive and
-> exclude the
-> last value.
->
-> Am I off in my own little world here or have others pondered this?
-> (Perhaps it has been brought up before?) I am not requesting
-> a change on
-> this, I am merely pointing out what seems unnatural in a
-> very natural
-> language.
->
-> Zach
->


23 Answers

Zach Dennis

9/30/2004 3:54:00 PM

0

Mills Thomas (app1tam) wrote:

>Okay, maybe we think of it this way. '..' is a club. '...' is a club, with
>a bouncer at the door.
>
>Or, '..' is a path. '...' has a marble tripping up the last entry and
>pushing it off the path.
>
>Or, '..' represents a 2-dimensions (a vector). And '...' represents two
>dimensions with a daemon kicking the last entry into its own exclusion
>dimension (a plane) to live forever, planely in lonely solitude.
>
>Or, maybe I should quit now...Drew
>
This thinking imposes that the reasoning of the syntax should conform to
the syntax. I would think that the syntax should conform to the reasoning.

Zach

Zach Dennis

9/30/2004 3:55:00 PM

0

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.

Zach

Henrik Horneber

9/30/2004 4:19:00 PM

0

Zach Dennis 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.
>
> Zach
>
>

Indeed. I was not really thinking this to the end.

Thanks all!

Henrik

Martin DeMello

9/30/2004 7:25:00 PM

0

Zach Dennis <zdennis@mktec.com> 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 can't think of any better reason than "inclusive ranges are the common
case, so make them simpler"

martin

Gavin Sinclair

10/1/2004 2:00:00 AM

0

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.

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.

Speaking as a Ruby programmer again, I personally find nothing whatsoever
confusing about the literal range notation, inclusive or exclusive. And I
dislike the thought of reversing the notations; not based on precedent and
not wanting to change things, but based an aesthetics. And trying to
explain why is like trying to explain appreciation for a poem.

Cheers,
Gavin

Zach Dennis

10/1/2004 2:17:00 AM

0

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

Gavin Sinclair

10/1/2004 6:36:00 AM

0







<415C2C00.7070608@mktec.com>
<49058.129.94.6.30.1096595962.squirrel@webmail.imagineis.com>
<415C86F3.9050102@mktec.com>
X-ML-Name: ruby-talk
X-Mail-Count: 114460
X-MLServer: fml [fml 4.0.3 release (20011202/4.0.3)]; post only (only members can post)
X-ML-Info: If you have a question, send e-mail with the body
"help" (without quotes) to the address ruby-talk-ctl@ruby-lang.org;
help=<mailto:ruby-talk-ctl@ruby-lang.org?body=help>
X-Mailer: SquirrelMail (version 1.2.7)
X-Priority: 3
Importance: Normal
X-MSMail-Priority: Normal
X-Spam-Checker-Version: SpamAssassin 3.0.0 (2004-09-13) on
beryllium.ruby-lang.org
X-Spam-Status: No, score=-2.6 required=7.0 tests=AWL,BAYES_00 autolearn=ham
version=3.0.0
X-Spam-Level:
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Precedence: bulk
Lines: 113
List-Id: ruby-talk.ruby-lang.org
List-Software: fml [fml 4.0.3 release (20011202/4.0.3)]
List-Post: <mailto:ruby-talk@ruby-lang.org>
List-Owner: <mailto:ruby-talk-admin@ruby-lang.org>
List-Help: <mailto:ruby-talk-ctl@ruby-lang.org?body=help>
List-Unsubscribe: <mailto:ruby-talk-ctl@ruby-lang.org?body=unsubscribe>
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at ruby-lang.org
X-Amavis-Alert: BAD HEADER Improper folded header field made up entirely of whitespace (char 00 hex) in message header 'References'
^
X-Virus-Scanned: Sophos MailMonitor on mail.zrz.tu-berlin.de;
Fri, 01 Oct 2004 08:36:50 +0200

Zach wrote:

> 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".

To me, neither seems "more natural" once prior experience is removed.
It's quite arbitrary. If you think it's more natural a certain way,
then go ahead, but it's unlikely to convince me.

>>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, neither. It's not been a problem when teaching people Ruby.
Those people were existing programmers of other languages, but I doubt
they were familiar with .. from anywhere.

I'll also point out, as I'm fond of doing, that you learn a language --
and of course, to learn programming at all -- you have to be willing to
actually *learn* a few things. I like to see it made as easy as
possible, but there are other considerations as well. This particular
piece of syntax took me no time at all to learn, and I'm not
extraordianarily brilliant, so I have no concern that it is confusing
for newbies. (I was one, once, and it wasn't confusing.)

> 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.

Well I do. But that's probably because I take the attitude that it's
arbitrary, that it might as well be kept simple, and because that
notation looks better than any reasonable alternative I can think of.

> 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 inclusive and exclusive ranges were a significant goal of the
language, then my first thought would be this:

[x,y]
[x,y)
(x,y]
(x,y)

However, that's almost certainly going to clash with other goals of the
language, like representing arrays, etc. So it's time for plan B. Of
course, this language doesn't _rally_ need ranges as flexible as the
above representation allows, does it?

# BTW, I'm not entirely happy with Ruby's ranges, I'll have you know.
# They are only really useful for integers and perhaps some strings,
# but they _try_ to be useful for anything, and kind of botch it.
# Further, they take two otherwise aliases methods -- member? and
# include? -- and make them mean something different. This is poor
# form, IMO. They're trying to do too much.

So in my new language, I'd say "ranges are for integers only", and use
the .. and ... notations. Which one for inclusive and which one for
exclusive? To be honest, I don't care. Either one of them would make
sense once you're used to it. So, inclusive being the more common case,
perhaps I'd optimise it accordingly.

> 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.

I haven't seen any other attempts to portray logical reasoning towards
an unbiased conclusion, so I feel I'm in good company :)

Cheers,
Gavin

Steve Brumbaugh

10/1/2004 6:52:00 AM

0

Hello! I'd like to help translate some of the Japanese documentation to
English, but am not sure where to begin. I found a list of pending
translations at <http://www.rubygarden.org/ruby?TranslationsInPr..., but
the list is quite out of date. I've also searched ruby-talk and ruby-list, but
didn't immediately find any current information.

Does anybody have suggestions for getting started? I'd hate to duplicate the
work of other people.

Best,
Steve



_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote...

Mauricio Fernández

10/1/2004 10:13:00 AM

0

On Fri, Oct 01, 2004 at 03:52:07PM +0900, Steve Brumbaugh wrote:
> Hello! I'd like to help translate some of the Japanese documentation to
> English, but am not sure where to begin. I found a list of pending
> translations at <http://www.rubygarden.org/ruby?TranslationsInPr..., but
> the list is quite out of date. I've also searched ruby-talk and ruby-list, but
> didn't immediately find any current information.
>
> Does anybody have suggestions for getting started? I'd hate to duplicate the
> work of other people.

Not exactly documentation, but I think many people would be happy
to have a translation of

http://jp.rubyist.net...

--
Running Debian GNU/Linux Sid (unstable)
batsman dot geo at yahoo dot com

T. Onoma

10/1/2004 11:00:00 AM

0

On Friday 01 October 2004 02:36 am, Gavin Sinclair wrote:
> So in my new language, I'd say "ranges are for integers only", and use
> the .. and ... notations.  Which one for inclusive and which one for
> exclusive?  To be honest, I don't care.  Either one of them would make
> sense once you're used to it.  So, inclusive being the more common case,
> perhaps I'd optimise it accordingly.

Well, while were at it here's mine:

0..9 inclusive
0..9.0 exclusive

And .. would be a method.

BTW: why can I say 'a=1,2' and get an array, but not 'a=(1,2)' ?

T.