On Fri, 11 Feb 2011 09:06:06 -0500, Ary Manzana <ary@esperanto.org.ar> wrote:

> On 2/11/11 12:15 AM, Nick Sabalausky wrote:
>> "Andrej Mitrovic"<andrej.mitrovich@gmail.com>  wrote in message
>> news:mailman.1476.1297391467.4748.digitalmars-d@puremagic.com...
>>> What the hell does "to!" have to do with anything. Disregard my last
>>> post, it's obviously 3 AM and I'm talking gibberish.
>>>
>>
>> I just meant that "iota" looks a lot like (spaces added for clarity) "i   to
>> a". In other words, the first time I ever saw "iota", I confused it for the
>> old C function that converts an integer to an ASCII string. It may very well
>> have been 3am for me at the time ;)
>
> You are the second one who confuses iota with itoa. Actually, the third, I confused it too.
>
> According to the book "The Design of Everyday Things" the design of that function name is wrong, it's not your fault and it's not because it was 3am. When many people make mistakes with regards to the design of something it's *always* the design's fault, never the human's fault.

Also, C code is callable from D.  consider a seasoned d coder who sees code like:

auto x = itoa(5);

what is he going to thing x is?

-Steve

Am 10.02.2011 12:40, schrieb spir:
> 
> Certainly, because it's /highly/ important for a community of programmers to share the same "culture". And names are the main support & vehicle for this culture.
> 
> Denis
> 
> (For this reason, I stoppped aliasing size_t and size_diff_t to Ordinal and
> Cardinal ;-) I use uint everywhere)
> 

This will cause trouble on 64bit systems, because there size_t is ulong.

Cheers,
- Daniel

On 02/11/2011 03:32 PM, Daniel Gibson wrote:
> Am 10.02.2011 12:40, schrieb spir:
>>
>> Certainly, because it's /highly/ important for a community of programmers to
>> share the same "culture". And names are the main support&  vehicle for this
>> culture.
>>
>> Denis
>>
>> (For this reason, I stoppped aliasing size_t and size_diff_t to Ordinal and
>> Cardinal ;-) I use uint everywhere)
>>
>
> This will cause trouble on 64bit systems, because there size_t is ulong.

Yes and No. For pointers and mem diffs, yes. But for 99% uses of cardinals and ordinals uint is by far big enough.

Denis
-- 
_________________
vita es estrany
spir.wikidot.com

spir:

> But for 99% uses of cardinals and ordinals uint is by far big enough.

Then in D2 for those use an int. Unsigned values are _very_ bug-prone in D2.

Bye,
bearophile

On 2/10/11 5:29 PM, Sean Kelly wrote:
> Andrei Alexandrescu Wrote:
>>
>> I don't find the name "iota" stupid.
>
> I never entirely understood the name choice.  I suppose "iota" could be related to a "small step" so iota(1,5) is a series of small steps from 1 to 5?

Pretty much, with the note that the smallest nondegenerated integral step is 1 :o).

The name "iota" makes perfect sense to me, I knew what it does in the STL from its signature before reading its definition. There are people who don't like it, there are people who do, and there are people who simply pick up the name and use it. I don't see how to improve global happiness.


Andrei

On 2/10/11 8:28 PM, Andrej Mitrovic wrote:
> What the hell does "to!" have to do with anything. Disregard my last
> post, it's obviously 3 AM and I'm talking gibberish.
>
> In any case,
> alias iota range;
>
> Problem solved for me!

Aside from the fact that "range" has another meaning in D, the word does not convey the notion that iota adds incremental steps to move from one number to another. "Iota" does convey that notion.

Andrei

On 2/11/11, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
> On 2/10/11 8:28 PM, Andrej Mitrovic wrote:
>> What the hell does "to!" have to do with anything. Disregard my last post, it's obviously 3 AM and I'm talking gibberish.
>>
>> In any case,
>> alias iota range;
>>
>> Problem solved for me!
>
> Aside from the fact that "range" has another meaning in D, the word does not convey the notion that iota adds incremental steps to move from one number to another. "Iota" does convey that notion.
>
> Andrei
>

So why does Python use it?

It seems Go uses iota, but for something different: http://golang.org/doc/go_spec.html#Iota

That's rather ugly imo. But that's Go. :)

bearophile Wrote:
> Then in D2 for those use an int. Unsigned values are _very_ bug-prone in D2.

May I ask why?

Jim:

> bearophile Wrote:
> > Then in D2 for those use an int. Unsigned values are _very_ bug-prone in D2.
> 
> May I ask why?

Because:
- D unsigned numbers are fixed-sized bitfields, they overflow. (Multi-precision values are not built-in, they are currently slow if you need a 30 or 50 or 70 bit long value, and generally they feel like grafted on the language).
- There are no run-time overflow errors, as in C#/Delphi/etc (this is ridiculous for any language that hopes to make safety one of its strong points. Delphi has this feature since ages ago. Not having this in D is like going back to 1980 or before. It gives a peculiar stone-age style to the whole D language).
- D copies the weird/bad C signed-unsigned conversion rules, that cause plenty of troubles.
- D doesn't have warnings like GCC that give a bit of help against the C signed-unsigned conversion rules, nor against things like unsigned<0.

In Delphi using unsigned numbers is safer, but in D it's actually safer to use signed values :-) All this is compound with the design choice of using signed values for arrays and indexes in D.

One even less bright design decision was to use unsigned longs for array positions, etc: http://d.puremagic.com/issues/show_bug.cgi?id=5452

Generally in the current D the best advice is to limit the usage of unsigned values as much as possible, and use them only in the uncommon situations where they are needed, like:
- When you need the full range of 8, 16, 32 or 64 bits. This is uncommon, but it happens. Example: you really want to save memory to store indexes and you need you will have no more than about 40_000 items. Then use an ushort.
- To store bitfields, like an array of 50_000 bits, to implement a bit set, some kind of bitmap, bloom filter, etc.
- When you need to deserialize or receive data from some channel or memory, that you know is for example a 32 unsigned int or 16 bit unsigned int, a unsigned 8 bit digital signal from some instrument, etc.

In most other cases it's better to use signed values, for example you will avoid several bugs if in your code you use lines of code like:
int len = array.length;
and then you use len in the rest of your function.

Bye,
bearophile

Andrei:

> Aside from the fact that "range" has another meaning in D, the word does not convey the notion that iota adds incremental steps to move from one number to another. "Iota" does convey that notion.

I have accepted  the "iota" name, it's short, easy to remember, it has one historical usage in APL, and "Range" has another meaning in D (but it's weird, and it's something you need to learn, it's not something a newbie is supposed to know before reading D2 docs well. The name "interval" is better, simpler to understand, but it's longer for a so common function).

But this answer of yours is stepping outside the bounds of reasonableness :-) If you ask a pool of 20 programmers what range(10,20) or iota(10,20) means, I'm sure more people will guess range() correctly than iota(). The word range() do convey a complete enumeration of values in an interval. iota() does not convey that.

Said all this, I suggest to introduce the first-class a..b interval syntax in D (or even a..b:c), this is able to remove most (all?) usage of iota().

Bye,
bearophile