[Python-ideas] Tail Call Optimization -- natural? intuitive?

Ryan Gonzalez rymg19 at gmail.com
Mon Jan 20 19:36:12 CET 2014


+1 for the example you used.


On Mon, Jan 20, 2014 at 7:09 AM, Chris Angelico <rosuav at gmail.com> wrote:

> On Mon, Jan 20, 2014 at 11:12 PM, spir <denis.spir at gmail.com> wrote:
> > For instance, closed intervals are more intuitive or natural, obviously
> (but
> > for some reason I don't know). If you ask someone to count from 1 to 9,
> you
> > will probably be surprised to hear him/her start from 2 or stop after 8.
> If
> > you are asked to choose a letter between c and g, you will probably be
> > surprised to hear that 'c' or 'g' is no good choice.
>
> I'm not so sure about that. The half-open interval makes as much sense
> as the fully closed - all you have to do is interpret the indices as
> being *between* elements. Take, for example, Scripture verses. (Quotes
> taken from THE HOLY BIBLE, NEW INTERNATIONAL VERSION®, NIV® Copyright
> © 1973, 1978, 1984, 2011 by Biblica, Inc.® Used by permission. All
> rights reserved worldwide. Copyright notice included for license
> compliance. Note that I'm using bracketed numbers to indicate the
> beginnings of verses - in a printed Bible, these would normally be in
> superscript.)
>
> John 14:
> [31] To the Jews who had believed him, Jesus said, “If you hold to my
> teaching, you are really my disciples. [32] Then you will know the
> truth, and the truth will set you free.” [33]
>
> This passage is normally referred to as "John 14:31-32", but as you
> see, the verse marker [32] is in the middle of the quote. Using a
> half-open interval, this would start at "John 14:31" and end at "John
> 14:33". Half-open means: "Begin at the beginning, go on till you come
> to the end, then stop", as the King of Hearts instructed the White
> Rabbit.
>
> It's easy to indicate the beginning of a chapter: your start reference
> is verse 1. Here's the beginning of the account of the creation of the
> world:
>
> [1] In the beginning God created the heavens and the earth. [2] Now
> the earth was formless and empty, darkness was over the surface of the
> deep, and the Spirit of God was hovering over the waters. [3] And God
> said, “Let there be light,” and there was light. [4] God saw that the
> light was good, and he separated the light from the darkness. [5] God
> called the light “day,” and the darkness he called “night.” And there
> was evening, and there was morning—the first day. [6]
>
> Common parlance: Genesis 1:1-5. Half-open: Genesis 1:1-6. Conclusion:
> Tie. No argument to be made for either side. But what if you're
> looking at the *end* of a chapter? Here are a few verses from later on
> in Genesis 1:
>
> [29] Then God said, “I give you every seed-bearing plant on the face
> of the whole earth and every tree that has fruit with seed in it. They
> will be yours for food. [30] And to all the beasts of the earth and
> all the birds of the air and all the creatures that move on the
> ground—everything that has the breath of life in it—I give every green
> plant for food.” And it was so. [31] God saw all that he had made, and
> it was very good. And there was evening, and there was morning—the
> sixth day.
>
> Common parlance: Genesis 1:29-31. Half-open: Genesis 1:29-2:1. It's
> much more obvious by the latter that this passage extends exactly to
> the end of the chapter.
>
> Obviously it's way WAY too late to change the way Bible references are
> written, any more than Melway could renumber their maps all of a
> sudden. Massive case of lock-in and backward-incompatibility with
> existing code. But I put it to you that the half-open would make at
> least as much sense as the closed, in any situation where there are
> boundaries with contents between them.
>
> Note, by the way, that I'm not looking at anything involving backward
> scanning or wider strides, both of which Python's slice notation
> supports. Neither of those is inherently real-world intuitive, so the
> exact semantics can be defined as whatever makes sense in code. (And
> there was some discussion a little while ago about exactly that.) I'm
> just looking at the very simple and common case of referencing a
> subset of consecutive elements from a much larger whole.
>
> The closed interval makes more sense when the indices somehow *are*
> the values being retrieved. When you count from 1 to 9, you expect
> nine numbers: 1, 2, ..., 8, 9. When you list odd numbers from 1 to 9,
> you expect 1, 3, 5, 7, 9. But what if you're looking at a container
> train and numbering the twenty-foot-equivalent-units (TEU) that it
> has? A 40-foot container requires 2 TEU, a 60-foot container requires
> 3 TEU. A "reefer" (refridgerated container) might require an extra
> slot, or at least it might be a 56-footer and consume 3 TEU. One wagon
> might, if you're lucky, carry 5 TEU; numbering them 1 through 5 would
> be obvious, but numbering the boundaries between them as 0 through 5
> is better at handling the multiple TEU containers. (Even more so when
> you look at double-stacked containers. An over-height 40-foot
> container could consume 2 TEU horizontally and 2 TEU vertically, and
> be put in slots (0,0)-(2,2). This is, in fact, exactly how a GTK2
> Table layout works.) Both types of intervals have their places.
>
> ChrisA
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>



-- 
Ryan
When your hammer is C++, everything begins to look like a thumb.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20140120/ce979e46/attachment.html>


More information about the Python-ideas mailing list