"Nick Sabalausky" <a a.a> writes:

AUIU, foreach has both of these forms:

    foreach(x; 0..5)
    foreach(x; someRange)

Also, we have:

    auto someRange = iota(0, 5);

Little idea: How about this genralized lowering?

    0..5
    // iota says "Gimme some sugar, baby."
    // and thus it is lowered to ->
    iota(0, 5)

Of course, if that hinders optimization for foreach(x; 0..5), then the 
compiler could just "optimize" that particular case by not bothering with 
the lowering and doing as it currently does.

But the benefit is things like this:

    // Stealing Andrei's "filter even" example:
    filter!`a % 2 == 0`(iota(1, 5))
    // Give iota some sugar, baby:
    filter!`a % 2 == 0`(1..5)

I suppose the obnoxious float-literal definition could get in the way, but 
when is it ever legal syntax in D to have two numeric literals next to each 
other? (And foreach seems ok with it anyway)

Pardon if this has already been suggested.

Peter Alexander <peter.alexander.au gmail.com> writes:

On 9/02/11 3:08 AM, Nick Sabalausky wrote:
 AUIU, foreach has both of these forms:

      foreach(x; 0..5)
      foreach(x; someRange)

 Also, we have:

      auto someRange = iota(0, 5);

 <snip>
 Pardon if this has already been suggested.

I have suggested it in the past, and I believe people had suggested it 
before me. I agree, it does make perfect sense to add that syntax, 
although it probably shouldn't be tied into Phobos (maybe add a druntime 
version of iota?)

bearophile <bearophileHUGS lycos.com> writes:

Nick Sabalausky:

 AUIU, foreach has both of these forms:

D is currently very not-orthogonal.

I have added the enhancement request time ago:
http://d.puremagic.com/issues/show_bug.cgi?id=5395
http://d.puremagic.com/issues/show_bug.cgi?id=4112

Bye,
bearophile

%u <e ee.com> writes:

== Quote from bearophile (bearophileHUGS lycos.com)'s article
 D is currently very not-orthogonal.

I think you might the person to ask this:
I've seen the concept of orthogonality pop up more and more and it was
especially
prominent in the awkward Go vs D reddit discussion, can you maybe explain what
it
exactly means?
And, also how it relates to your enhancement?

 I have added the enhancement request time ago:
 http://d.puremagic.com/issues/show_bug.cgi?id=5395
 http://d.puremagic.com/issues/show_bug.cgi?id=4112
 Bye,
 bearophile

bearophile <bearophileHUGS lycos.com> writes:

%u:

 can you maybe explain what it exactly means?
 And, also how it relates to your enhancement?

In programming languages it means features that have fully separated purposes,
that can be combined together in clean and safe ways to create more complex
functionalities. Combining in "clean and safe ways" means they don't have
unwanted interactions, their lower level nature is sufficiently encapsulated
and doesn't leak out too much, so their sub-systems are mostly sealed, if you
want to see it with systems theory ideas.

In the current discussion foreach(i;iota(5)) and foreach(i;0..5) are usable for
the same purpose, so those two "features" don't have fully separated purposes.
On the other hand you can't use 0..5 where you want a lazy range:
auto r = 0 .. 5;
You need to us iota:
auto r = iota(0, 5);
So the 0..5 can't be combined to many other language functionalities to produce
something bigger.
This is why several people have asked for a more orthogonal interval syntax in
D.

Bye,
bearophile

%u <e ee.com> writes:

== Quote from bearophile (bearophileHUGS lycos.com)'s article
 %u:
 can you maybe explain what it exactly means?
 And, also how it relates to your enhancement?

 In programming languages it means features that have fully separated purposes,

that can be combined together in clean and safe ways to create more complex
functionalities. Combining in "clean and safe ways" means they don't have
unwanted
interactions, their lower level nature is sufficiently encapsulated and doesn't
leak out too much, so their sub-systems are mostly sealed, if you want to see it
with systems theory ideas.
 In the current discussion foreach(i;iota(5)) and foreach(i;0..5) are usable for

the same purpose, so those two "features" don't have fully separated purposes.
On
the other hand you can't use 0..5 where you want a lazy range:
 auto r = 0 .. 5;
 You need to us iota:
 auto r = iota(0, 5);
 So the 0..5 can't be combined to many other language functionalities to produce

something bigger.
 This is why several people have asked for a more orthogonal interval syntax in
D.
 Bye,
 bearophile

Thanks!!

int[3] arr = [0..5:2];

spir <denis.spir gmail.com> writes:

On 02/09/2011 04:08 AM, Nick Sabalausky wrote:
 AUIU, foreach has both of these forms:

      foreach(x; 0..5)
      foreach(x; someRange)

 Also, we have:

      auto someRange = iota(0, 5);

 Little idea: How about this genralized lowering?

      0..5
      // iota says "Gimme some sugar, baby."
      // and thus it is lowered to ->
      iota(0, 5)

 Of course, if that hinders optimization for foreach(x; 0..5), then the
 compiler could just "optimize" that particular case by not bothering with
 the lowering and doing as it currently does.

 But the benefit is things like this:

      // Stealing Andrei's "filter even" example:
      filter!`a % 2 == 0`(iota(1, 5))
      // Give iota some sugar, baby:
      filter!`a % 2 == 0`(1..5)

 I suppose the obnoxious float-literal definition could get in the way, but
 when is it ever legal syntax in D to have two numeric literals next to each
 other? (And foreach seems ok with it anyway)

 Pardon if this has already been suggested.

I like this. Maybe a slightly different approach would be for both 1..5 and 
iota(1,5) to be expressions for a simple and range-semantic-compatible 
struct-like thingy. Then, actually, iota would be superfluous, but some may 
still like it syntactically or semantically (because Iota is explicitely 
defined as a range type).
Side-question: what is actually 1..5 as of now for a thing? Or is it 
conceptually "unconstructed" by rewriting to (probably) an ordinary for loop? 
Anyway, the point above applies to language-side semantics, whatever 
optimisation may happen.

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

"Nick Sabalausky" <a a.a> writes:

"spir" <denis.spir gmail.com> wrote in message 
news:mailman.1422.1297254724.4748.digitalmars-d puremagic.com...
 Side-question: what is actually 1..5 as of now for a thing? Or is it 
 conceptually "unconstructed" by rewriting to (probably) an ordinary for 
 loop? Anyway, the point above applies to language-side semantics, whatever 
 optimisation may happen.

AIUI: Syntactically, it doesn't exist at all, at least not by itself. It's 
just part of one of the foreach syntaxes:

  'foreach' '(' {declaration list} ';' {expression} '..' {expression} ')'

and also part of one of the slice syntaxes:

  (from the docs:)
  PostfixExpression [ AssignExpression .. AssignExpression ]

Although it's possible I've understood it wrong.

Don't have a clue how it's handled beyond that though.

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

On 2/9/11 7:46 AM, Nick Sabalausky wrote:
 "spir"<denis.spir gmail.com>  wrote in message
 news:mailman.1422.1297254724.4748.digitalmars-d puremagic.com...
 Side-question: what is actually 1..5 as of now for a thing? Or is it
 conceptually "unconstructed" by rewriting to (probably) an ordinary for
 loop? Anyway, the point above applies to language-side semantics, whatever
 optimisation may happen.

 AIUI: Syntactically, it doesn't exist at all, at least not by itself. It's
 just part of one of the foreach syntaxes:

    'foreach' '(' {declaration list} ';' {expression} '..' {expression} ')'

 and also part of one of the slice syntaxes:

    (from the docs:)
    PostfixExpression [ AssignExpression .. AssignExpression ]

 Although it's possible I've understood it wrong.

 Don't have a clue how it's handled beyond that though.

Indeed, a..b is just punctuation in the two grammatical constructs you 
mentioned.

Your proposal has indeed been made a couple of times, first probably by 
bearophile - but then what did bearophile /not/ propose? (Meaning this 
in good fun.) I think it would be okay to move iota into druntime and 
enact the rewrite. But this would improve the language by such a small 
iota...

I buy the orthogonality argument as much as you do. foreach is not 
orthogonal because it is a short form of for, which is not orthogonal 
because it is a short form of while, which is not orthogonal because it 
is a short form of a scope with if/goto at the top.

If a..b would be rewritten into iota(a, b) that would still be 
non-orthogonal because one could express one thing in two ways. 
Ironically, it's more orthogonal to leave things as they are: you have 
iota(a, b) as the general concept and you have a..b as punctuation in 
two grammatical constructs.

But the most important question is: if the rewrite were done, to what 
extent would that improve your use of the language? Integral intervals 
do occur outside foreach and slices, but quite infrequently. In those 
cases you'd gain by replacing iota(a, b) with a..b. Is this significant?


Andrei

bearophile <bearophileHUGS lycos.com> writes:

Andrei:

 But the most important question is: if the rewrite were done, to what extent
would that improve your use of the language? Integral intervals do occur
outside foreach and slices, but quite infrequently. In those cases you'd gain
by replacing iota(a, b) with a..b. Is this significant?<

I can list you why I think an interval syntax is better, but at the end you
need to judge values:

- The basic range syntax is already present in two different situations in the
language, for slices and foreach (switch-case statement use the dot-dot syntax
for a related but different purpose). So D programmers don't need to learn a
new syntax, the cognitive cost is probably negative.

- The 1 .. 5 syntax is present in math too (even if it often means a set closed
on the right too).

- There is no need to learn to use a function with a weird syntax like iota,
coming from APL. This makes Phobos and learning D a bit simpler.

- Both 1..5 and iota(1,5) are able to support the "in" operator. This is good
because D doesn't support the a<X<b Python syntax.  X in a..b will mean a<=X<b.

- If the compiler front-end becomes aware of the interval syntax, it is able to
perform "3 in 1..10" at compile-time too, simplifying sub-expressions even when
they are inside other run-time expressions.

- With the interval syntax there is no need to import std.range, that's
necessary for iota().

- the a..b syntax is shorter and a bit less noisy:  array(1..5) compared to
array(iota(1,5)).

- The a..b syntax is extendible to cover the third stride argument of iota(). I
suggest a..b:c  (The stride syntax is later usable for arrays too if the stride
is a compile-time constant). Python shows several nice usages of the stride
argument.

- Currently foreach(i; retro(iota(...))) or even foreach(i; iota(...)) are not
as fast as foreach(i; ...). I hope this interval syntax will help DMD digest a
lazy interval more efficiently.

- Interesting point, to translate this to interval syntax: iota(1.,-5.) it
becomes 1...5. that's a mess. You need zeros:  1.0 .. 5.0

- Another interesting point, currently the semantics of iota() and the interval
in foreach are not the same, only the second loop here raises an exception:

import std.stdio, std.range;
void main() {
    foreach (x; 1 .. -5)
        writeln(x);
    foreach (x; iota(1, -5))
        writeln(x);
}

In my opinion iota() semantics here must be the same as the foreach interval,
and yield an empty iterable with no errors:
http://d.puremagic.com/issues/show_bug.cgi?id=4603


I like the interval literal syntax for static things too, example:
http://d.puremagic.com/issues/show_bug.cgi?id=4085
static foreach (x; 1 .. -5)

A first class literal syntax in D (typeid(typeof(1..5)) gives a new type) may
become useful for slices too in objects/structs, this is Python 2.6 code:


class Foo(object):
    def __getitem__(self, key):
        print key
f = Foo()
f[1:2]


Output:
slice(1, 2, None)

Bye,
bearophile

Daniel Gibson <metalcaedes gmail.com> writes:

Am 09.02.2011 19:54, schrieb bearophile:
 
 - Both 1..5 and iota(1,5) are able to support the "in" operator. This is good
because D doesn't support the a<X<b Python syntax.  X in a..b will mean a<=X<b.
 

Don't know about Python, but in D this will only be true if X is an integer.
I guess 1<X<4 is true for X=1.5 in Python.. it would certainly not be true for X
in 1..4 in D.
Also using X in 1..4 is in D is pretty bad if you just want to check if 1<X<4
(or even more when checking 1<X<100) because it has a much higher overhead -
even though it may be technically O(1) because 4 or 100 is a constant) than just
doing two comparisons. So IMHO using X in 1..4 or x in iota(1,4) should not be
encouraged. (X in [1,3,4,8] is different.)
Of course the compiler could transform X in 1..4 to X>1 && X<4, but... I don't
think it's a good idea.
If this syntax is accepted, 1..4 should create a range/array containing [1,2,3]
- without addidional voodoo.

 - If the compiler front-end becomes aware of the interval syntax, it is able
to perform "3 in 1..10" at compile-time too, simplifying sub-expressions even
when they are inside other run-time expressions.
 


Cheers,
- Daniel

bearophile <bearophileHUGS lycos.com> writes:

Daniel Gibson:

 Don't know about Python, but in D this will only be true if X is an integer.
 I guess 1<X<4 is true for X=1.5 in Python.. it would certainly not be true for
X
 in 1..4 in D.

You are right, the semantics is different, my silly mistake. Thank you.


 Also using X in 1..4 is in D is pretty bad if you just want to check if 1<X<4
 (or even more when checking 1<X<100) because it has a much higher overhead -
 even though it may be technically O(1) because 4 or 100 is a constant)

Even if the bounds are not constants it's not hard to perform  x in a..b  in
O(1).

Bye,
bearophile

Daniel Gibson <metalcaedes gmail.com> writes:

Am 09.02.2011 20:57, schrieb bearophile:
 Daniel Gibson:
 
 Don't know about Python, but in D this will only be true if X is an integer.
 I guess 1<X<4 is true for X=1.5 in Python.. it would certainly not be true for
X
 in 1..4 in D.

 
 You are right, the semantics is different, my silly mistake. Thank you.
 
 
 Also using X in 1..4 is in D is pretty bad if you just want to check if 1<X<4
 (or even more when checking 1<X<100) because it has a much higher overhead -
 even though it may be technically O(1) because 4 or 100 is a constant)

 
 Even if the bounds are not constants it's not hard to perform  x in a..b  in
O(1).
 

If the compiler does optimizations (=> transforms it to if( a<=x && x<b)), yes.
If a..b are handled as a generic range (just like e.g. [1, 10, 4, 7, 3, 42]) I
don't think it's as easy in constant time. Maybe when putting the range into a
hash table.. but this also has some overhead.

 Bye,
 bearophile

Cheers,
- Daniel

spir <denis.spir gmail.com> writes:

On 02/09/2011 08:06 PM, Daniel Gibson wrote:
 Also using X in 1..4 is in D is pretty bad if you just want to check if 1<X<4
 (or even more when checking 1<X<100) because it has a much higher overhead -
 even though it may be technically O(1) because 4 or 100 is a constant) than
just
 doing two comparisons. So IMHO using X in 1..4 or x in iota(1,4) should not be
 encouraged. (X in [1,3,4,8] is different.)

I don't understand your point, here. opIn (or rather opIn_r) ids just 2 
comparisons as well for whatever represents an interval i..j. Simulation below.

Denis

struct Interval {
     int min, maxPlusOne;
     bool opIn_r (int n) {
         return (n >= min) && (n < maxPlusOne);
     }
}
unittest {
     auto ii = Interval(1,4);
     auto ints = [-1,0,1,2,3,4,5];
     foreach (i ; ints) writefln ("%s ? %s", i, i in ii);
}
==>
-1 ? false
0 ? false
1 ? true
2 ? true
3 ? true
4 ? false
5 ? false

-- 
_________________
vita es estrany
spir.wikidot.com

Ary Manzana <ary esperanto.org.ar> writes:

On 2/9/11 3:54 PM, bearophile wrote:
 - There is no need to learn to use a function with a weird syntax like iota,
coming from APL. This makes Phobos and learning D a bit simpler.

I would recommend stop using "weird" names for functions. Sorry if this 
sounds a little harsh but the only reason I see this function is called 
"iota" is to demonstrate knowledge (or to sound cool). But programmers 
using a language don't care about whether the other programmer 
demonstrates knowledge behind a function name, they just want to get 
things done, fast.

I mean, if I want to create a range of numbers I would search "range". 
"iota" will never, ever come to my mind. D has to be more open to 
public, not only to people who programmed in APL, Go or are mathematics 
freaks. Guess how a range is called in Ruby? That's right, Range.

Another example: retro. The documentation says "iterates a bidirectional 
name backwards". Hm, where does "retro" appear in that text? If I want 
to iterate it backwards, or to reverse the order, the first thing I 
would write is reverse(range) or backwards(range), "retro" would never 
come to my mind.

(and no, replies like "you can always alias xxx" are not accepted :-P)

Daniel Gibson <metalcaedes gmail.com> writes:

Am 09.02.2011 21:08, schrieb Ary Manzana:
 On 2/9/11 3:54 PM, bearophile wrote:
 - There is no need to learn to use a function with a weird syntax like iota,
 coming from APL. This makes Phobos and learning D a bit simpler.

 
 I would recommend stop using "weird" names for functions. Sorry if this sounds
a
 little harsh but the only reason I see this function is called "iota" is to
 demonstrate knowledge (or to sound cool). But programmers using a language
don't
 care about whether the other programmer demonstrates knowledge behind a
function
 name, they just want to get things done, fast.
 
 I mean, if I want to create a range of numbers I would search "range". "iota"
 will never, ever come to my mind. D has to be more open to public, not only to
 people who programmed in APL, Go or are mathematics freaks. Guess how a range
is
 called in Ruby? That's right, Range.
 
 Another example: retro. The documentation says "iterates a bidirectional name
 backwards". Hm, where does "retro" appear in that text? If I want to iterate it
 backwards, or to reverse the order, the first thing I would write is
 reverse(range) or backwards(range), "retro" would never come to my mind.
 
 (and no, replies like "you can always alias xxx" are not accepted :-P)

I agree that iota is a bad name, but "Range" is a bad name because it's already
used in D.

Cheers,
- Daniel

spir <denis.spir gmail.com> writes:

On 02/09/2011 09:09 PM, Daniel Gibson wrote:
 Am 09.02.2011 21:08, schrieb Ary Manzana:
 On 2/9/11 3:54 PM, bearophile wrote:
 - There is no need to learn to use a function with a weird syntax like iota,
 coming from APL. This makes Phobos and learning D a bit simpler.

 I would recommend stop using "weird" names for functions. Sorry if this sounds
a
 little harsh but the only reason I see this function is called "iota" is to
 demonstrate knowledge (or to sound cool). But programmers using a language
don't
 care about whether the other programmer demonstrates knowledge behind a
function
 name, they just want to get things done, fast.

 I mean, if I want to create a range of numbers I would search "range". "iota"
 will never, ever come to my mind. D has to be more open to public, not only to
 people who programmed in APL, Go or are mathematics freaks. Guess how a range
is
 called in Ruby? That's right, Range.

 Another example: retro. The documentation says "iterates a bidirectional name
 backwards". Hm, where does "retro" appear in that text? If I want to iterate it
 backwards, or to reverse the order, the first thing I would write is
 reverse(range) or backwards(range), "retro" would never come to my mind.

 (and no, replies like "you can always alias xxx" are not accepted :-P)

 I agree that iota is a bad name, but "Range" is a bad name because it's already
 used in D.

Use "Interval". Actually better than range, because it's an international word 
(thus far easier for non-native English speakers). English very often provides 
2 words (typically one is germanic, the other imported); choose the 
international one when none is obviously better.

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

Jacob Carlborg <doob me.com> writes:

On 2011-02-09 21:09, Daniel Gibson wrote:
 Am 09.02.2011 21:08, schrieb Ary Manzana:
 On 2/9/11 3:54 PM, bearophile wrote:
 - There is no need to learn to use a function with a weird syntax like iota,
 coming from APL. This makes Phobos and learning D a bit simpler.

 I would recommend stop using "weird" names for functions. Sorry if this sounds
a
 little harsh but the only reason I see this function is called "iota" is to
 demonstrate knowledge (or to sound cool). But programmers using a language
don't
 care about whether the other programmer demonstrates knowledge behind a
function
 name, they just want to get things done, fast.

 I mean, if I want to create a range of numbers I would search "range". "iota"
 will never, ever come to my mind. D has to be more open to public, not only to
 people who programmed in APL, Go or are mathematics freaks. Guess how a range
is
 called in Ruby? That's right, Range.

 Another example: retro. The documentation says "iterates a bidirectional name
 backwards". Hm, where does "retro" appear in that text? If I want to iterate it
 backwards, or to reverse the order, the first thing I would write is
 reverse(range) or backwards(range), "retro" would never come to my mind.

 (and no, replies like "you can always alias xxx" are not accepted :-P)

 I agree that iota is a bad name, but "Range" is a bad name because it's already
 used in D.

 Cheers,
 - Daniel

But "range"?

-- 
/Jacob Carlborg

=?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:

Ary Manzana wrote:
 On 2/9/11 3:54 PM, bearophile wrote:
 - There is no need to learn to use a function with a weird syntax like=


 iota, coming from APL. This makes Phobos and learning D a bit simpler.=


=20
 I would recommend stop using "weird" names for functions. Sorry if this=

 sounds a little harsh but the only reason I see this function is called=

 "iota" is to demonstrate knowledge (or to sound cool). But programmers
 using a language don't care about whether the other programmer
 demonstrates knowledge behind a function name, they just want to get
 things done, fast.
=20
 I mean, if I want to create a range of numbers I would search "range".
 "iota" will never, ever come to my mind. D has to be more open to
 public, not only to people who programmed in APL, Go or are mathematics=

 freaks. Guess how a range is called in Ruby? That's right, Range.
=20
 Another example: retro. The documentation says "iterates a bidirectiona=

l
 name backwards". Hm, where does "retro" appear in that text? If I want
 to iterate it backwards, or to reverse the order, the first thing I
 would write is reverse(range) or backwards(range), "retro" would never
 come to my mind.
=20

	Well, at least =E2=80=9Cretro=E2=80=9D is compatible with the dictionary=

signification of the word, so even though it is not the first word
that would come to mind when searching how to reverse a list, it
should be pretty self explanatory when reading existing code.

	OTOH, =E2=80=9Ciota=E2=80=9D is not and could even be argued to be anton=
ymous to
the dictionary meaning, which makes it all that much more difficult
to understand.

		Jerome
--=20
mailto:jeberger free.fr
http://jeberger.free.fr
Jabber: jeberger jabber.fr

Olivier Pisano <olivier.pisano laposte.net> writes:

Le 09/02/2011 21:08, Ary Manzana a �crit :
 On 2/9/11 3:54 PM, bearophile wrote:
 - There is no need to learn to use a function with a weird syntax like
 iota, coming from APL. This makes Phobos and learning D a bit simpler.

 I would recommend stop using "weird" names for functions. Sorry if this
 sounds a little harsh but the only reason I see this function is called
 "iota" is to demonstrate knowledge (or to sound cool). But programmers
 using a language don't care about whether the other programmer
 demonstrates knowledge behind a function name, they just want to get
 things done, fast.

 I mean, if I want to create a range of numbers I would search "range".
 "iota" will never, ever come to my mind. D has to be more open to
 public, not only to people who programmed in APL, Go or are mathematics
 freaks. Guess how a range is called in Ruby? That's right, Range.

 Another example: retro. The documentation says "iterates a bidirectional
 name backwards". Hm, where does "retro" appear in that text? If I want
 to iterate it backwards, or to reverse the order, the first thing I
 would write is reverse(range) or backwards(range), "retro" would never
 come to my mind.

 (and no, replies like "you can always alias xxx" are not accepted :-P)

Hi,

I agree iota is a bad name.
FWIW, what comes to my mind when I read it is an idea of tininess, such 
as in the expression : "It didn't change an iota". I certainly miss the 
mathematical reference.
Retro is self explanatory when you read it, even if it is not the first 
to come to mind. Backwards may have been better. Reverse is already in 
std.algorithm and would have confused the user.

Cheers,

Olivier.

spir <denis.spir gmail.com> writes:

On 02/10/2011 07:30 AM, Olivier Pisano wrote:
 Le 09/02/2011 21:08, Ary Manzana a écrit :
 On 2/9/11 3:54 PM, bearophile wrote:
 - There is no need to learn to use a function with a weird syntax like
 iota, coming from APL. This makes Phobos and learning D a bit simpler.

 I would recommend stop using "weird" names for functions. Sorry if this
 sounds a little harsh but the only reason I see this function is called
 "iota" is to demonstrate knowledge (or to sound cool). But programmers
 using a language don't care about whether the other programmer
 demonstrates knowledge behind a function name, they just want to get
 things done, fast.

 I mean, if I want to create a range of numbers I would search "range".
 "iota" will never, ever come to my mind. D has to be more open to
 public, not only to people who programmed in APL, Go or are mathematics
 freaks. Guess how a range is called in Ruby? That's right, Range.

 Another example: retro. The documentation says "iterates a bidirectional
 name backwards". Hm, where does "retro" appear in that text? If I want
 to iterate it backwards, or to reverse the order, the first thing I
 would write is reverse(range) or backwards(range), "retro" would never
 come to my mind.

 (and no, replies like "you can always alias xxx" are not accepted :-P)

 Hi,

 I agree iota is a bad name.
 FWIW, what comes to my mind when I read it is an idea of tininess, such as in
 the expression : "It didn't change an iota". I certainly miss the mathematical
 reference.

What math sense. Maybe iota used for other meanings in english speaking math 
(would be surprised). I only know 2 uses: an alternative for imaginary 'i' or 
'j', and the module of length 1 along X-axis.
The latter obviously has some connexion with the notion of range, but it 
conflicts in fact, in that iota means a /single/ unit step, and range firstly 
denotes a series of values, not of steps/offsets between them.

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

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

On 2/10/11 12:30 AM, Olivier Pisano wrote:
 Le 09/02/2011 21:08, Ary Manzana a �crit :
 On 2/9/11 3:54 PM, bearophile wrote:
 - There is no need to learn to use a function with a weird syntax like
 iota, coming from APL. This makes Phobos and learning D a bit simpler.

 I would recommend stop using "weird" names for functions. Sorry if this
 sounds a little harsh but the only reason I see this function is called
 "iota" is to demonstrate knowledge (or to sound cool). But programmers
 using a language don't care about whether the other programmer
 demonstrates knowledge behind a function name, they just want to get
 things done, fast.

 I mean, if I want to create a range of numbers I would search "range".
 "iota" will never, ever come to my mind. D has to be more open to
 public, not only to people who programmed in APL, Go or are mathematics
 freaks. Guess how a range is called in Ruby? That's right, Range.

 Another example: retro. The documentation says "iterates a bidirectional
 name backwards". Hm, where does "retro" appear in that text? If I want
 to iterate it backwards, or to reverse the order, the first thing I
 would write is reverse(range) or backwards(range), "retro" would never
 come to my mind.

 (and no, replies like "you can always alias xxx" are not accepted :-P)

 Hi,

 I agree iota is a bad name.

Fifth result of simply googling the entire Web for "iota":

http://www.sgi.com/tech/stl/iota.html


Andrei

Max Samukha <maxsamukha spambox.com> writes:

On 02/10/2011 05:18 PM, Andrei Alexandrescu wrote:
 On 2/10/11 12:30 AM, Olivier Pisano wrote:
 Le 09/02/2011 21:08, Ary Manzana a �crit :
 On 2/9/11 3:54 PM, bearophile wrote:
 - There is no need to learn to use a function with a weird syntax like
 iota, coming from APL. This makes Phobos and learning D a bit simpler.

 I would recommend stop using "weird" names for functions. Sorry if this
 sounds a little harsh but the only reason I see this function is called
 "iota" is to demonstrate knowledge (or to sound cool). But programmers
 using a language don't care about whether the other programmer
 demonstrates knowledge behind a function name, they just want to get
 things done, fast.

 I mean, if I want to create a range of numbers I would search "range".
 "iota" will never, ever come to my mind. D has to be more open to
 public, not only to people who programmed in APL, Go or are mathematics
 freaks. Guess how a range is called in Ruby? That's right, Range.

 Another example: retro. The documentation says "iterates a bidirectional
 name backwards". Hm, where does "retro" appear in that text? If I want
 to iterate it backwards, or to reverse the order, the first thing I
 would write is reverse(range) or backwards(range), "retro" would never
 come to my mind.

 (and no, replies like "you can always alias xxx" are not accepted :-P)

 Hi,

 I agree iota is a bad name.

 Fifth result of simply googling the entire Web for "iota":

 http://www.sgi.com/tech/stl/iota.html


 Andrei

Google search takes your preferences into account. They must be tracking 
your search history, peeking into your gmail accounts etc. I searched 
for 'iota' and couldn't find the STL link on the first 5 pages.

spir <denis.spir gmail.com> writes:

On 02/10/2011 04:34 PM, Max Samukha wrote:
 On 02/10/2011 05:18 PM, Andrei Alexandrescu wrote:
 On 2/10/11 12:30 AM, Olivier Pisano wrote:
 Le 09/02/2011 21:08, Ary Manzana a écrit :
 On 2/9/11 3:54 PM, bearophile wrote:
 - There is no need to learn to use a function with a weird syntax like
 iota, coming from APL. This makes Phobos and learning D a bit simpler.

 I would recommend stop using "weird" names for functions. Sorry if this
 sounds a little harsh but the only reason I see this function is called
 "iota" is to demonstrate knowledge (or to sound cool). But programmers
 using a language don't care about whether the other programmer
 demonstrates knowledge behind a function name, they just want to get
 things done, fast.

 I mean, if I want to create a range of numbers I would search "range".
 "iota" will never, ever come to my mind. D has to be more open to
 public, not only to people who programmed in APL, Go or are mathematics
 freaks. Guess how a range is called in Ruby? That's right, Range.

 Another example: retro. The documentation says "iterates a bidirectional
 name backwards". Hm, where does "retro" appear in that text? If I want
 to iterate it backwards, or to reverse the order, the first thing I
 would write is reverse(range) or backwards(range), "retro" would never
 come to my mind.

 (and no, replies like "you can always alias xxx" are not accepted :-P)

 Hi,

 I agree iota is a bad name.

 Fifth result of simply googling the entire Web for "iota":

 http://www.sgi.com/tech/stl/iota.html


 Andrei

 Google search takes your preferences into account. They must be tracking your
 search history, peeking into your gmail accounts etc. I searched for 'iota' and
 couldn't find the STL link on the first 5 pages.

Even then, noone forces D2 to blindly reproduce stupid naming from APL/C++, I 
guess. Or what?

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

=?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:

spir wrote:
 Even then, noone forces D2 to blindly reproduce stupid naming from
 APL/C++, I guess. Or what?
=20

	Actually, I thought that D had set out to *fix* the stupid mistakes
from C++...

		Jerome
--=20
mailto:jeberger free.fr
http://jeberger.free.fr
Jabber: jeberger jabber.fr

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

On 2/10/11 9:47 AM, spir wrote:
 On 02/10/2011 04:34 PM, Max Samukha wrote:
 On 02/10/2011 05:18 PM, Andrei Alexandrescu wrote:
 On 2/10/11 12:30 AM, Olivier Pisano wrote:
 Le 09/02/2011 21:08, Ary Manzana a écrit :
 On 2/9/11 3:54 PM, bearophile wrote:
 - There is no need to learn to use a function with a weird syntax
 like
 iota, coming from APL. This makes Phobos and learning D a bit
 simpler.

 I would recommend stop using "weird" names for functions. Sorry if
 this
 sounds a little harsh but the only reason I see this function is
 called
 "iota" is to demonstrate knowledge (or to sound cool). But programmers
 using a language don't care about whether the other programmer
 demonstrates knowledge behind a function name, they just want to get
 things done, fast.

 I mean, if I want to create a range of numbers I would search "range".
 "iota" will never, ever come to my mind. D has to be more open to
 public, not only to people who programmed in APL, Go or are
 mathematics
 freaks. Guess how a range is called in Ruby? That's right, Range.

 Another example: retro. The documentation says "iterates a
 bidirectional
 name backwards". Hm, where does "retro" appear in that text? If I want




 Path: digitalmars.com!not-for-mail
 From: Regan Heath <regan netwin.co.nz>
 Newsgroups: digitalmars.D
 Subject: Re: Lookup conventions: [Was Re: Get vs Test method naming
 convention]
 Date: Thu, 15 Jul 2004 12:25:06 +1200
 Organization: Netwin LTD
 Lines: 145
 Message-ID: <opsa5kr4zf5a2sq9 digitalmars.com>
 References: <cd30iv$17m8$1 digitaldaemon.com>
 <cd3qim$2iov$1 digitaldaemon.com> <cd481o$adi$4 digitaldaemon.com>
 <cd4dqj$m1f$1 digitaldaemon.com> <cd4gnr$rp0$1 digitaldaemon.com>
 Mime-Version: 1.0
 Content-Type: text/plain; format=flowed; charset=iso-8859-15
 Content-Transfer-Encoding: 8bit
 X-Trace: digitaldaemon.com 1089851223 33174 210.54.44.56 (15 Jul 2004
 00:27:03 GMT)
 X-Complaints-To: usenet digitalmars.com
 NNTP-Posting-Date: Thu, 15 Jul 2004 00:27:03 +0000 (UTC)
 User-Agent: Opera7.23/Win32 M2 build 3227
 Xref: digitalmars.com digitalmars.D:6162

 On Thu, 15 Jul 2004 09:47:52 +1000, Matthew
 <admin stlsoft.dot.dot.dot.dot.org> wrote:
 "Sean Kelly" <sean f4.ca> wrote in message
 news:cd4dqj$m1f$1 digitaldaemon.com...
 In article <cd481o$adi$4 digitaldaemon.com>, Matthew says...
Fair point

What about:

 - value_type getXyz(key_type key) returns the requested element, or


 throw
InvalidKeyException
 - bool containsXyz(key_type key) returns true/false, indicating


 presence
of element
 - value_type findXyx(key_type key, value_type defaultValue) returns

 the
requested element, or the given default

 - opIndex() is a synonym for getXyz where the container has only a


 single
value_type, or its primary value_type is obviously delineated from any


 secondary
value_types.

I'm pretty happy with this picture. Votes?

 I don't like the new findXyz semantics. The new function requires that I

 either
 set aside a potentially valid value to signal lookup failure, do two
 lookups
 (one for containsXyz and another for findXyz), or wrap getXyz in a
 try block.
 Another possibility would be to offer two versions of findXyz, one
 accepting a
 default and one returning a pointer?

 Can you provide a quick sample of using a findXyz() that illustrates your
 requirement?


 Ok, assuming that everyone's on board with testing (by opIn and/or
 contains()
 and/or containsXyz()) and getting (opIndex and/or get() and/or
 getXyz()), then
 it's finding that's the trouble.

 What are our requirements for finding:

 To be able to determine presence (testing) and retrieve the element in
 the case of its being present.

 To determine presence we must either return a boolean or sentinel
 value (e.g.
 null). Given the dichotomy between null being a good (but not perfect)
 sentinel
 for object types, and 0/NaN being a bad sentinel for built-in types,
 I'd now
 suggest that we don't do that. Hence, presence should be indicated
 either by
 return value, or by an out parameter.
 Retrieval can similarly be return value or out parameter.

 Thus, for finding, we have two options

 1. Return the value, pass the presence as an out parameter

 value_type findXyz(key_type key, out bool bPresent);

 2. Return the presence, pass the value as an out parameter

 bool findXyz(key_type key, out value_type value);



 if (findXyz("regan",value)) {
 }



 value = findXyz("regan",r);
 if (r) {
 }

 I'd suggest here and now that neither of these are going to satisfy all
 circumstances. I'd further suggest, however, that we need to decide on
 one and
 stick to it.



 btw, considering all this, it now seems to me that the above
 definition of
 findXyz(), incorporating a default value, is quite wrong. That should
 be called
 something else, findWithDefault[Xyz](), or something less ugly.

 True, having a default value requires being able to pass 'no default',
 which is the null/0/NaN problem all over again.

 Do we need this at all, consider:

 if (!findXyz("regan",value)) value = "default";
 ..use value here..

 Leaving us with the following lookup "conventions":

 to iterate it backwards, or to reverse the order, the first thing I
 would write is reverse(range) or backwards(range), "retro" would never
 come to my mind.

 (and no, replies like "you can always alias xxx" are not accepted :-P)

 Hi,

 I agree iota is a bad name.

 Fifth result of simply googling the entire Web for "iota":

 http://www.sgi.com/tech/stl/iota.html


 Andrei

 Google search takes your preferences into account. They must be
 tracking your
 search history, peeking into your gmail accounts etc. I searched for
 'iota' and
 couldn't find the STL link on the first 5 pages.

 Even then, noone forces D2 to blindly reproduce stupid naming from
 APL/C++, I guess. Or what?

I don't find the name "iota" stupid.

Andrei

Sean Kelly <sean invisibleduck.org> writes:

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?

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

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

"Nick Sabalausky" <a a.a> writes:

"Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
news:ij1nkf$i7g$2 digitalmars.com...
 I don't find the name "iota" stupid.

Far as I can tell, you seem to be nearly the only one who finds it to be a 
good name. I can live with it, since I've just simply learned that in D 
"iota(x,y)" means "range of integers from [x,y)". And the controversy over 
it's name helps me to remember. But still, I'm yet another in the seemingly 
much larger camp of "The word 'iota' doesn't remotely reflect what it does". 
Additionally, I've never known any other meaning for "iota" besides "vey 
small amount", I've never used APL, and I've certainly never used 
non-standard SGI extensions to C++.

(Actually, the first time I saw "iota()", my thought was "Wait, I thought D 
used the much more readable to!string(7)...oh, wait, that says iota, not 
itoa..." But that might just be my problem ;) )

FWIW, I do like "retro". 

Jonathan M Davis <jmdavisProg gmx.com> writes:

On Thursday, February 10, 2011 17:45:21 Nick Sabalausky wrote:
 "Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message
 news:ij1nkf$i7g$2 digitalmars.com...
 
 I don't find the name "iota" stupid.

 
 Far as I can tell, you seem to be nearly the only one who finds it to be a
 good name. I can live with it, since I've just simply learned that in D
 "iota(x,y)" means "range of integers from [x,y)". And the controversy over
 it's name helps me to remember. But still, I'm yet another in the seemingly
 much larger camp of "The word 'iota' doesn't remotely reflect what it
 does". Additionally, I've never known any other meaning for "iota" besides
 "vey small amount", I've never used APL, and I've certainly never used
 non-standard SGI extensions to C++.
 
 (Actually, the first time I saw "iota()", my thought was "Wait, I thought D
 used the much more readable to!string(7)...oh, wait, that says iota, not
 itoa..." But that might just be my problem ;) )
 
 FWIW, I do like "retro".

I feel pretty much the same way. iota seems like a horrible name as far as 
figuring out what the function does from its name goes. I don't know what a
good 
name would be though (genSequence?), but since I know what it does, it doesn't 
confuse me when I see it. It does have the advantage of being short at least.

So, I don't think that it's a good name, but I don't think that it's worth 
changing either. retro is a good name though. But there _are_ going to be 
functions with relatively poor names, and it's not like we'll ever get
agreement 
on all function names anyway.

- Jonathan m Davis

Andrej Mitrovic <andrej.mitrovich gmail.com> writes:

Make to! smarter?

auto someRange = to!range(0, 5);

Here's python:
 range(5, 10)



[5, 6, 7, 8, 9]
 range(0, 10, 3)



[0, 3, 6, 9]
 range(-10, -100, -30)



[-10, -40, -70]

And D would be:
to!range(5, 10);
to!range(5, 10, 3);
to!range(-1, -100, -30);

But abusing the range word might be bad. I dunno..

spir <denis.spir gmail.com> writes:

On 02/11/2011 03:06 AM, Jonathan M Davis wrote:
 I feel pretty much the same way. iota seems like a horrible name as far as
 figuring out what the function does from its name goes. I don't know what a
good
 name would be though (genSequence?)

why not "interval"? (not obvious enough ;-)

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

Jacob Carlborg <doob me.com> writes:

On 2011-02-10 23:05, Andrei Alexandrescu wrote:
 On 2/10/11 9:47 AM, spir wrote:
 Even then, noone forces D2 to blindly reproduce stupid naming from
 APL/C++, I guess. Or what?

 I don't find the name "iota" stupid.

 Andrei

Of course you don't think it's stupid, you named it. It starts to look 
more and more that you are the only one that likes it. How about we vote 
about it ?

-- 
/Jacob Carlborg

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

On 2/11/11 2:46 AM, Jacob Carlborg wrote:
 On 2011-02-10 23:05, Andrei Alexandrescu wrote:
 On 2/10/11 9:47 AM, spir wrote:
 Even then, noone forces D2 to blindly reproduce stupid naming from
 APL/C++, I guess. Or what?

 I don't find the name "iota" stupid.

 Andrei

 Of course you don't think it's stupid, you named it. It starts to look
 more and more that you are the only one that likes it. How about we vote
 about it ?

Sure. Have at it! I'll be glad to comply with the vote.

Andrei

Ary Manzana <ary esperanto.org.ar> writes:

On 2/10/11 12:34 PM, Max Samukha wrote:
 On 02/10/2011 05:18 PM, Andrei Alexandrescu wrote:
 On 2/10/11 12:30 AM, Olivier Pisano wrote:
 Le 09/02/2011 21:08, Ary Manzana a �crit :
 On 2/9/11 3:54 PM, bearophile wrote:
 - There is no need to learn to use a function with a weird syntax like
 iota, coming from APL. This makes Phobos and learning D a bit simpler.

 I would recommend stop using "weird" names for functions. Sorry if this
 sounds a little harsh but the only reason I see this function is called
 "iota" is to demonstrate knowledge (or to sound cool). But programmers
 using a language don't care about whether the other programmer
 demonstrates knowledge behind a function name, they just want to get
 things done, fast.

 I mean, if I want to create a range of numbers I would search "range".
 "iota" will never, ever come to my mind. D has to be more open to
 public, not only to people who programmed in APL, Go or are mathematics
 freaks. Guess how a range is called in Ruby? That's right, Range.

 Another example: retro. The documentation says "iterates a
 bidirectional
 name backwards". Hm, where does "retro" appear in that text? If I want
 to iterate it backwards, or to reverse the order, the first thing I
 would write is reverse(range) or backwards(range), "retro" would never
 come to my mind.

 (and no, replies like "you can always alias xxx" are not accepted :-P)

 Hi,

 I agree iota is a bad name.

 Fifth result of simply googling the entire Web for "iota":

 http://www.sgi.com/tech/stl/iota.html


 Andrei

 Google search takes your preferences into account. They must be tracking
 your search history, peeking into your gmail accounts etc. I searched
 for 'iota' and couldn't find the STL link on the first 5 pages.

Same here. And 5th isn't very good. 1st is very good. :-P

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

On 2/10/11 9:49 AM, Ary Manzana wrote:
 On 2/10/11 12:34 PM, Max Samukha wrote:
 On 02/10/2011 05:18 PM, Andrei Alexandrescu wrote:
 On 2/10/11 12:30 AM, Olivier Pisano wrote:
 Le 09/02/2011 21:08, Ary Manzana a �crit :
 On 2/9/11 3:54 PM, bearophile wrote:
 - There is no need to learn to use a function with a weird syntax
 like
 iota, coming from APL. This makes Phobos and learning D a bit
 simpler.

 I would recommend stop using "weird" names for functions. Sorry if
 this
 sounds a little harsh but the only reason I see this function is
 called
 "iota" is to demonstrate knowledge (or to sound cool). But programmers
 using a language don't care about whether the other programmer
 demonstrates knowledge behind a function name, they just want to get
 things done, fast.

 I mean, if I want to create a range of numbers I would search "range".
 "iota" will never, ever come to my mind. D has to be more open to
 public, not only to people who programmed in APL, Go or are
 mathematics
 freaks. Guess how a range is called in Ruby? That's right, Range.

 Another example: retro. The documentation says "iterates a
 bidirectional
 name backwards". Hm, where does "retro" appear in that text? If I want
 to iterate it backwards, or to reverse the order, the first thing I
 would write is reverse(range) or backwards(range), "retro" would never
 come to my mind.

 (and no, replies like "you can always alias xxx" are not accepted :-P)

 Hi,

 I agree iota is a bad name.

 Fifth result of simply googling the entire Web for "iota":

 http://www.sgi.com/tech/stl/iota.html


 Andrei

 Google search takes your preferences into account. They must be tracking
 your search history, peeking into your gmail accounts etc. I searched
 for 'iota' and couldn't find the STL link on the first 5 pages.

 Same here. And 5th isn't very good. 1st is very good. :-P

One misconception is that iota is a range of numbers. It's not. The step 
is an important part of it.

Andrei

"Nick Sabalausky" <a a.a> writes:

"Max Samukha" <maxsamukha spambox.com> wrote in message 
news:ij10n7$25p0$1 digitalmars.com...
 On 02/10/2011 05:18 PM, Andrei Alexandrescu wrote:
 On 2/10/11 12:30 AM, Olivier Pisano wrote:
 Le 09/02/2011 21:08, Ary Manzana a �crit :
 On 2/9/11 3:54 PM, bearophile wrote:
 - There is no need to learn to use a function with a weird syntax like
 iota, coming from APL. This makes Phobos and learning D a bit simpler.

 I would recommend stop using "weird" names for functions. Sorry if this
 sounds a little harsh but the only reason I see this function is called
 "iota" is to demonstrate knowledge (or to sound cool). But programmers
 using a language don't care about whether the other programmer
 demonstrates knowledge behind a function name, they just want to get
 things done, fast.

 I mean, if I want to create a range of numbers I would search "range".
 "iota" will never, ever come to my mind. D has to be more open to
 public, not only to people who programmed in APL, Go or are mathematics
 freaks. Guess how a range is called in Ruby? That's right, Range.

 Another example: retro. The documentation says "iterates a 
 bidirectional
 name backwards". Hm, where does "retro" appear in that text? If I want
 to iterate it backwards, or to reverse the order, the first thing I
 would write is reverse(range) or backwards(range), "retro" would never
 come to my mind.

 (and no, replies like "you can always alias xxx" are not accepted :-P)

 Hi,

 I agree iota is a bad name.

 Fifth result of simply googling the entire Web for "iota":

 http://www.sgi.com/tech/stl/iota.html


 Andrei

 Google search takes your preferences into account. They must be tracking 
 your search history, peeking into your gmail accounts etc. I searched for 
 'iota' and couldn't find the STL link on the first 5 pages.

Yea, it's definitely user-specific. It's on the thrid page for me. But the 
second result on the first page is the Wikipedia page for "Iota" which 
mentions the following meanings:

- A greek letter
- A small amount
- "Imaginary" constant
- The "definite descriptor" (symbolic logic).
- The unit vector (but generally with a superscribed caret)

The only reference on the page to a sequence of integers is in direct 
reference to APL (which is kind of obsure outside numerical-computation) and 
*ahem* "Issue 9" (which isn't exactly a fountain of good ideas to be 
stolen).

Additionally, keep in mind that on that SGI/STL page, it states "This 
function is an SGI extension; it is not part of the C++ standard". So it's 
not even C++ or STL at all, it's a non-standard SGI extension (And is SGI 
stuff even used anymore anyway? Do they even exist as what we know "SGI" as 
being anymore?).

spir <denis.spir gmail.com> writes:

On 02/11/2011 02:38 AM, Nick Sabalausky wrote:
 "Max Samukha"<maxsamukha spambox.com>  wrote in message
 news:ij10n7$25p0$1 digitalmars.com...
 On 02/10/2011 05:18 PM, Andrei Alexandrescu wrote:
 On 2/10/11 12:30 AM, Olivier Pisano wrote:
 Le 09/02/2011 21:08, Ary Manzana a écrit :
 On 2/9/11 3:54 PM, bearophile wrote:
 - There is no need to learn to use a function with a weird syntax like
 iota, coming from APL. This makes Phobos and learning D a bit simpler.

 I would recommend stop using "weird" names for functions. Sorry if this
 sounds a little harsh but the only reason I see this function is called
 "iota" is to demonstrate knowledge (or to sound cool). But programmers
 using a language don't care about whether the other programmer
 demonstrates knowledge behind a function name, they just want to get
 things done, fast.

 I mean, if I want to create a range of numbers I would search "range".
 "iota" will never, ever come to my mind. D has to be more open to
 public, not only to people who programmed in APL, Go or are mathematics
 freaks. Guess how a range is called in Ruby? That's right, Range.

 Another example: retro. The documentation says "iterates a
 bidirectional
 name backwards". Hm, where does "retro" appear in that text? If I want
 to iterate it backwards, or to reverse the order, the first thing I
 would write is reverse(range) or backwards(range), "retro" would never
 come to my mind.

 (and no, replies like "you can always alias xxx" are not accepted :-P)

 Hi,

 I agree iota is a bad name.

 Fifth result of simply googling the entire Web for "iota":

 http://www.sgi.com/tech/stl/iota.html


 Andrei

 Google search takes your preferences into account. They must be tracking
 your search history, peeking into your gmail accounts etc. I searched for
 'iota' and couldn't find the STL link on the first 5 pages.

 Yea, it's definitely user-specific. It's on the thrid page for me.



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

so <so so.so> writes:

 Google search takes your preferences into account. They must be tracking  
 your search history, peeking into your gmail accounts etc.

I sooo hate that, it kills the very meaning of searching!

Andrej Mitrovic <andrej.mitrovich gmail.com> writes:

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!

"Nick Sabalausky" <a a.a> writes:

"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 ;)

Andrej Mitrovic <andrej.mitrovich gmail.com> writes:

On 2/11/11, Nick Sabalausky <a a.a> 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 ;)

Oh, sorry if it appeared I quoted you, but I wasn't quoting you I was
quoting myself and my silly to!range thingy.

I still don't even know what iota stands for. Is it an abbreviation?
It sounds like a word that came out of nowhere.

"Nick Sabalausky" <a a.a> writes:

"Andrej Mitrovic" <andrej.mitrovich gmail.com> wrote in message 
news:mailman.1477.1297394949.4748.digitalmars-d puremagic.com...
 On 2/11/11, Nick Sabalausky <a a.a> 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 ;)

 Oh, sorry if it appeared I quoted you, but I wasn't quoting you I was
 quoting myself and my silly to!range thingy.

Apperently you're not the only one that's tired and talking gibberish ;)

Jacob Carlborg <doob me.com> writes:

On 2011-02-11 04:15, 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 ;)

I thought that as well that first time I saw it.

-- 
/Jacob Carlborg

Ary Manzana <ary esperanto.org.ar> writes:

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.

"Steven Schveighoffer" <schveiguy yahoo.com> writes:

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.

Me 2.

 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.

I love that book, I wish more software engineers used it.  One of my  
favorite classes at college.

-Steve

"Nick Sabalausky" <a a.a> writes:

"Steven Schveighoffer" <schveiguy yahoo.com> wrote in message 
news:op.vqqsdxcaeav7ka steve-laptop...
 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.

 I love that book, I wish more software engineers used it.  One of my 
 favorite classes at college.

I probably would have liked that class if my college hadn't degenerated it 
into nothing more than "group VB6 project". Bleh. I always hated group 
projects.  /me "Does not play well with others."

I really should actually read that book. I've heard a lot about what it 
says, and I like everything I've heard. Even without having read it, it's 
still influenced me a fair amount.

"Steven Schveighoffer" <schveiguy yahoo.com> writes:

On Fri, 11 Feb 2011 17:03:13 -0500, Nick Sabalausky <a a.a> wrote:

 "Steven Schveighoffer" <schveiguy yahoo.com> wrote in message
 news:op.vqqsdxcaeav7ka steve-laptop...
 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.

 I love that book, I wish more software engineers used it.  One of my
 favorite classes at college.

 I probably would have liked that class if my college hadn't degenerated  
 it
 into nothing more than "group VB6 project". Bleh. I always hated group
 projects.  /me "Does not play well with others."

 From what I can remember, I did not have to write any code in that class.   
I had to pick an item in my household and write a paper on what features  
were well designed and which ones were poor.  I have a feeling you would  
have loved that ;)

-Steve

"Nick Sabalausky" <a a.a> writes:

"Steven Schveighoffer" <schveiguy yahoo.com> wrote in message 
news:op.vqrewtcfeav7ka steve-laptop...
 On Fri, 11 Feb 2011 17:03:13 -0500, Nick Sabalausky <a a.a> wrote:

 "Steven Schveighoffer" <schveiguy yahoo.com> wrote in message
 news:op.vqqsdxcaeav7ka steve-laptop...
 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.

 I love that book, I wish more software engineers used it.  One of my
 favorite classes at college.

 I probably would have liked that class if my college hadn't degenerated 
 it
 into nothing more than "group VB6 project". Bleh. I always hated group
 projects.  /me "Does not play well with others."

 From what I can remember, I did not have to write any code in that class. 
 I had to pick an item in my household and write a paper on what features 
 were well designed and which ones were poor.  I have a feeling you would 
 have loved that ;)

lol, that's a good point, I probably could have had a lot of fun with that 
:)

bearophile <bearophileHUGS lycos.com> writes:

Nick Sabalausky:

 I really should actually read that book.

Donald Norman is not a genius, he seems to lack both in engineering knowledge
and classic literary culture, but despite this he has the right mindset to
explore the world and he does look a lot at the world and its things, so he
ends saying many interesting things. I suggest to read all books written by him
:-) 

Bye,
bearophile

"Steven Schveighoffer" <schveiguy yahoo.com> writes:

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

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

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

Andrej Mitrovic <andrej.mitrovich gmail.com> writes:

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 <bearophileHUGS lycos.com> writes:

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

"Nick Sabalausky" <a a.a> writes:

"bearophile" <bearophileHUGS lycos.com> wrote in message 
news:ij473k$1tfn$1 digitalmars.com...
 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().

I like "interval", too.

I do think the name "iota" is a nice extra reason to just use a..b or a..b:c 
like you say. It also makes it clear that it's a series of discrete values 
rather than a true mathematical range, since that's exactly how foreach 
already uses a..b: as a series of discrete values.

Don <nospam nospam.com> writes:

Nick Sabalausky wrote:
 "bearophile" <bearophileHUGS lycos.com> wrote in message 
 news:ij473k$1tfn$1 digitalmars.com...
 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().

 
 I like "interval", too.
 
 I do think the name "iota" is a nice extra reason to just use a..b or a..b:c 
 like you say. It also makes it clear that it's a series of discrete values 
 rather than a true mathematical range, since that's exactly how foreach 
 already uses a..b: as a series of discrete values.

I don't like interval at all, because I don't think it includes the 
notion of 'stepping'. An interval is just, everything from A to B, 
without necessarily specifying how you reach everything in that 
interval. Whereas iota includes the stepping.
(I would like to see intervals in the language, but just as an [a,b] pair).

OTOH iota() is unintuitive to me, and I do keep reading it as itoa().
Sadly I don't have any better suggestions.

"Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:

On Fri, 18 Feb 2011 22:10:37 +0100, Don wrote:

 Nick Sabalausky wrote:
 I like "interval", too.
 
 I do think the name "iota" is a nice extra reason to just use a..b or
 a..b:c like you say. It also makes it clear that it's a series of
 discrete values rather than a true mathematical range, since that's
 exactly how foreach already uses a..b: as a series of discrete values.

 
 I don't like interval at all, because I don't think it includes the
 notion of 'stepping'. An interval is just, everything from A to B,
 without necessarily specifying how you reach everything in that
 interval. Whereas iota includes the stepping. (I would like to see
 intervals in the language, but just as an [a,b] pair).
 
 OTOH iota() is unintuitive to me, and I do keep reading it as itoa().
 Sadly I don't have any better suggestions.

I have a similar range in SciD, which is called steps().  It differs from 
iota() in that a) you specify the number of steps instead of the step 
size and b) it only iterates over FP numbers and ensures that the first 
and last iterated values are in fact exactly the endpoints you specify.

I guess steps() would be a possible name for iota(), but then I would 
have to come up with a new name for my range. ;)

-Lars

"Simen kjaeraas" <simen.kjaras gmail.com> writes:

Lars T. Kyllingstad <public kyllingen.nospamnet> wrote:

 I guess steps() would be a possible name for iota(), but then I would
 have to come up with a new name for my range. ;)

Might I suggest iota()? ;)


-- 
Simen

"Nick Sabalausky" <a a.a> writes:

"Don" <nospam nospam.com> wrote in message 
news:ijmndc$3e5$1 digitalmars.com...
 Nick Sabalausky wrote:
 I like "interval", too.

 I do think the name "iota" is a nice extra reason to just use a..b or 
 a..b:c like you say. It also makes it clear that it's a series of 
 discrete values rather than a true mathematical range, since that's 
 exactly how foreach already uses a..b: as a series of discrete values.

 I don't like interval at all, because I don't think it includes the notion 
 of 'stepping'. An interval is just, everything from A to B, without 
 necessarily specifying how you reach everything in that interval. Whereas 
 iota includes the stepping.
 (I would like to see intervals in the language, but just as an [a,b] 
 pair).

 OTOH iota() is unintuitive to me, and I do keep reading it as itoa().
 Sadly I don't have any better suggestions.

I do agree that 'interval' is inaccurate because it doesn't imply stepping, 
but I still find 'iota' to be more inaccurate, it just means "a small 
amount", it carries no notion of range or endpoints or anything like that.

Justin Bogner <mail justinbogner.com> writes:

Don <nospam nospam.com> writes:
 I don't like interval at all, because I don't think it includes the
 notion of 'stepping'. An interval is just, everything from A to B,
 without necessarily specifying how you reach everything in that
 interval. Whereas iota includes the stepping.
 (I would like to see intervals in the language, but just as an [a,b] pair).

 OTOH iota() is unintuitive to me, and I do keep reading it as itoa().
 Sadly I don't have any better suggestions.

Woudn't "step" be fairly appropriate? It does generate a step function
after all.

"Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:

On Wed, 09 Feb 2011 17:08:10 -0300, Ary Manzana wrote:

 On 2/9/11 3:54 PM, bearophile wrote:
 - There is no need to learn to use a function with a weird syntax like
 iota, coming from APL. This makes Phobos and learning D a bit simpler.

 
 I would recommend stop using "weird" names for functions. Sorry if this
 sounds a little harsh but the only reason I see this function is called
 "iota" is to demonstrate knowledge (or to sound cool). 

I believe 'iota' got its name from its sibling in C++'s STL:

    http://www.sgi.com/tech/stl/iota.html

-Lars

spir <denis.spir gmail.com> writes:

On 02/09/2011 09:08 PM, Ary Manzana wrote:
 On 2/9/11 3:54 PM, bearophile wrote:
 - There is no need to learn to use a function with a weird syntax like iota,
 coming from APL. This makes Phobos and learning D a bit simpler.

 I would recommend stop using "weird" names for functions. Sorry if this sounds
 a little harsh but the only reason I see this function is called "iota" is to
 demonstrate knowledge (or to sound cool). But programmers using a language
 don't care about whether the other programmer demonstrates knowledge behind a
 function name, they just want to get things done, fast.

 I mean, if I want to create a range of numbers I would search "range". "iota"
 will never, ever come to my mind. D has to be more open to public, not only to
 people who programmed in APL, Go or are mathematics freaks. Guess how a range
 is called in Ruby? That's right, Range.

 Another example: retro. The documentation says "iterates a bidirectional name
 backwards". Hm, where does "retro" appear in that text? If I want to iterate it
 backwards, or to reverse the order, the first thing I would write is
 reverse(range) or backwards(range), "retro" would never come to my mind.

I completely share your points, here.
About iota, while I cannot speak for the English language, in mine (Fr) iota 
means more or less <a tiny, irrelevant, difference>, typically used as "it 
hasn't (even) changed a iota". I can hardly make any connexion with the sense 
of range/interval. No idea why APL designers used this name, but for sure we 
should not reproduce their error.
Retro is far less problematic because at least the sense matches ;-) But I 
agree an unexpected name is a drawback even if semantically correct: I just 
spent some time searching for "reverse" precisely; I knew they func exists
but...

The problems is worse in Phobos, because functionality is split across 
moduleaccording to a non-obvious scheme (if any) (?). In any other language, 
searching for a func operating of foos, you'd just explore the foo module, 
right? In Phobos, you need to explore foo, functional, algorithm, bar & baz, 
and whatnot. Plus possibly some modules outside std properly speaking (core, C 
libs). Very annoying. The logic should be obvious, and at best what most 
programmers would expect.

 (and no, replies like "you can always alias xxx" are not accepted :-P)

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)

-- 
_________________
vita es estrany
spir.wikidot.com

Daniel Gibson <metalcaedes gmail.com> writes:

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

spir <denis.spir gmail.com> writes:

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

bearophile <bearophileHUGS lycos.com> writes:

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

Jim <bitcirkel yahoo.com> writes:

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

May I ask why?

bearophile <bearophileHUGS lycos.com> writes:

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

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 Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

On 2/11/11 8:32 AM, 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.

 Cheers,
 - Daniel

Yah... big problems on Phobos' 64-bit port.

Andrei

Brad Roberts <braddr puremagic.com> writes:

On 2/11/2011 4:07 PM, Andrei Alexandrescu wrote:
 On 2/11/11 8:32 AM, 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.

 Cheers,
 - Daniel

 
 Yah... big problems on Phobos' 64-bit port.
 
 Andrei

There were a lot of places that needed to change from uint to size_t, yes.  But
bugs by the use of unsigned.. a rather
small number.  Considering that I did the majority of the d2 64 bit work, I
think I can say that with confidence in it's
accuracy.

Later,
Brad

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

On 2/12/11 12:46 AM, Brad Roberts wrote:
 On 2/11/2011 4:07 PM, Andrei Alexandrescu wrote:
 On 2/11/11 8:32 AM, 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.

 Cheers,
 - Daniel

 Yah... big problems on Phobos' 64-bit port.

 Andrei

 There were a lot of places that needed to change from uint to size_t, yes. 
But bugs by the use of unsigned.. a rather
 small number.  Considering that I did the majority of the d2 64 bit work, I
think I can say that with confidence in it's
 accuracy.

 Later,
 Brad

Walter has a story of staring at a couple lines of code for hours, that 
was discussed in this forum.

Andrei

spir <denis.spir gmail.com> writes:

On 02/09/2011 04:08 AM, Nick Sabalausky wrote:
 AUIU, foreach has both of these forms:

      foreach(x; 0..5)
      foreach(x; someRange)

 Also, we have:

      auto someRange = iota(0, 5);

 Little idea: How about this genralized lowering?

      0..5
      // iota says "Gimme some sugar, baby."
      // and thus it is lowered to ->
      iota(0, 5)

 Of course, if that hinders optimization for foreach(x; 0..5), then the
 compiler could just "optimize" that particular case by not bothering with
 the lowering and doing as it currently does.

 But the benefit is things like this:

      // Stealing Andrei's "filter even" example:
      filter!`a % 2 == 0`(iota(1, 5))
      // Give iota some sugar, baby:
      filter!`a % 2 == 0`(1..5)

 I suppose the obnoxious float-literal definition could get in the way, but
 when is it ever legal syntax in D to have two numeric literals next to each
 other? (And foreach seems ok with it anyway)

 Pardon if this has already been suggested.

PS: your proposal would also logically allow, I guess, expressions like (n in 
min..max). Would love it.

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

"Nick Sabalausky" <a a.a> writes:

"spir" <denis.spir gmail.com> wrote in message 
news:mailman.1423.1297254917.4748.digitalmars-d puremagic.com...
 PS: your proposal would also logically allow, I guess, expressions like (n 
 in min..max). Would love it.

Unfortunately, not unless "in" was changed to allow "{expr} in {range}". And 
from prior discussions of "in", I seem to remember Walter and Andrei are 
strongly against allowing "in" to be used to check for element values rather 
than just AA keys.

But Andrei did recently propose an "any", IIRC, that would allow something 
like what you're suggesting.

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

On 2/9/11 7:54 AM, Nick Sabalausky wrote:
 "spir"<denis.spir gmail.com>  wrote in message
 news:mailman.1423.1297254917.4748.digitalmars-d puremagic.com...
 PS: your proposal would also logically allow, I guess, expressions like (n
 in min..max). Would love it.

 Unfortunately, not unless "in" was changed to allow "{expr} in {range}". And
 from prior discussions of "in", I seem to remember Walter and Andrei are
 strongly against allowing "in" to be used to check for element values rather
 than just AA keys.

 But Andrei did recently propose an "any", IIRC, that would allow something
 like what you're suggesting.

a in iota(min, max) is a O(1) operation so it could be allowed.

Andrei

spir <denis.spir gmail.com> writes:

On 02/09/2011 01:54 PM, Nick Sabalausky wrote:
 "spir"<denis.spir gmail.com>  wrote in message
 news:mailman.1423.1297254917.4748.digitalmars-d puremagic.com...
 PS: your proposal would also logically allow, I guess, expressions like (n
 in min..max). Would love it.

 Unfortunately, not unless "in" was changed to allow "{expr} in {range}". And
 from prior discussions of "in", I seem to remember Walter and Andrei are
 strongly against allowing "in" to be used to check for element values rather
 than just AA keys.

 But Andrei did recently propose an "any", IIRC, that would allow something
 like what you're suggesting.

IIRC, they did not argue against it for ranges specifically, but for it beeing 
O(n) for conceptually sequential collections like plain arrays, unlike for AAs, 
thus misleading in terms of efficiency. But 'in' is O(1) for an interval ;-) 
So, there is no reason to disallow it, instead such a feature would be both 
obvious & useful.

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

Jesse Phillips <jessekphillips+D gmail.com> writes:

%u Wrote:

 == Quote from bearophile (bearophileHUGS lycos.com)'s article
 D is currently very not-orthogonal.

 
 I think you might the person to ask this:
 I've seen the concept of orthogonality pop up more and more and it was
especially
 prominent in the awkward Go vs D reddit discussion, can you maybe explain what
it
 exactly means?
 And, also how it relates to your enhancement?

Orthogonal is one of those terms people like to use because it makes them sound
smart. Bearophile has provided a good explanation of how it relates to
programming languages, and hasn't been abusing the term.

The discussion on Reddit was awkward because there where a few that couldn't
consistently use 'orthogonal.' For example I got one person to say that for him
orthogonality is when there are no exceptions to a rule/feature, yet somehow
nested functions where not orthogonal.

Then even once everyone agrees on what the term means, there are good arguments
as to why you wouldn't want to be completely orthogonal. And at this point many
will just assert not being orthogonal is always bad, with the universal reason
being "It is something more you have to remember." Which is not the purpose of
orthogonality at all, and being orthogonal doesn't even mean you'll have less
to remember.

So my opinion is to just make a statement of what is wrong and leave whether it
is related to orthogonality out of it. And even if it is labeled correctly it
best to be specific anyway so people aren't left guessing as to why.

spir <denis.spir gmail.com> writes:

On 02/09/2011 08:20 PM, Jesse Phillips wrote:
 %u Wrote:

 == Quote from bearophile (bearophileHUGS lycos.com)'s article
 D is currently very not-orthogonal.

 I think you might the person to ask this:
 I've seen the concept of orthogonality pop up more and more and it was
especially
 prominent in the awkward Go vs D reddit discussion, can you maybe explain what
it
 exactly means?
 And, also how it relates to your enhancement?

 Orthogonal is one of those terms people like to use because it makes them
sound smart. Bearophile has provided a good explanation of how it relates to
programming languages, and hasn't been abusing the term.

 The discussion on Reddit was awkward because there where a few that couldn't
consistently use 'orthogonal.' For example I got one person to say that for him
orthogonality is when there are no exceptions to a rule/feature, yet somehow
nested functions where not orthogonal.

 Then even once everyone agrees on what the term means, there are good
arguments as to why you wouldn't want to be completely orthogonal. And at this
point many will just assert not being orthogonal is always bad, with the
universal reason being "It is something more you have to remember." Which is
not the purpose of orthogonality at all, and being orthogonal doesn't even mean
you'll have less to remember.

 So my opinion is to just make a statement of what is wrong and leave whether
it is related to orthogonality out of it. And even if it is labeled correctly
it best to be specific anyway so people aren't left guessing as to why.

"othogonal" is just a fashionable way of saing "independant.


Adjective

orthogonal (non-comparable)

    1. (geometry) pertaining to right angles; perpendicular (to)

           A chord and the radius that bisects it are orthogonal.

    2. (mathematics)
          1. Of two functions, linearly independent; having a zero inner
product.

                 The normal vector and tangent vector at a given point are 
orthogonal.

          2. Of a square matrix that is the inverse of its transpose
          3. Of a linear transformation that preserves angles
    3. (statistics) statistically independent, with reference to variates
    4. (software engineering) Able to be treated separately.

           The content of the message should be orthogonal to the means of its 
delivery.


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

Jesse Phillips <jessekphillips+D gmail.com> writes:

spir Wrote:

 Use "Interval". Actually better than range, because it's an international word 
 (thus far easier for non-native English speakers). English very often provides 
 2 words (typically one is germanic, the other imported); choose the 
 international one when none is obviously better.

I would have thought that Greek/Latin would have been a more "International
Word"

spir <denis.spir gmail.com> writes:

On 02/10/2011 11:50 PM, Jesse Phillips wrote:
 spir Wrote:

 Use "Interval". Actually better than range, because it's an international word
 (thus far easier for non-native English speakers). English very often provides
 2 words (typically one is germanic, the other imported); choose the
 international one when none is obviously better.

 I would have thought that Greek/Latin would have been a more "International
Word"

That's what I meant, but obviously was not clear. (Yes, very often 
international words means of greek/latin origin but there are numerous 
counter-examples in both senses; I mean greco-latin roots which have not been 
adopted in "international lexicon" --like range, precisely--, and international 
terms from other origins --like 'bug" ;-). ()

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

foobar <foo bar.com> writes:

Andrei Alexandrescu Wrote:

 
 I don't find the name "iota" stupid.
 
 Andrei

Of course _you_ don't. However practically all the users _do_ find it poorly
named, including other developers in the project.. 
This is the umpteenth time this comes up in the NG and incidentally this is the
only reason I know what the function does. 

If the users think the name is stupid than it really is. That's how usability
works and the fact the you think otherwise or that it might be more accurate
mathematically is really not relevant. If you want D/Phobos to be used by other
people besides yourself you need to cater for their requirements. 

"Nick Sabalausky" <a a.a> writes:

"foobar" <foo bar.com> wrote in message news:ij3cal$cee$1 digitalmars.com...
 Andrei Alexandrescu Wrote:

 I don't find the name "iota" stupid.

 Andrei

 Of course _you_ don't. However practically all the users _do_ find it 
 poorly named, including other developers in the project..
 This is the umpteenth time this comes up in the NG and incidentally this 
 is the only reason I know what the function does.

 If the users think the name is stupid than it really is. That's how 
 usability works and the fact the you think otherwise or that it might be 
 more accurate mathematically is really not relevant. If you want D/Phobos 
 to be used by other people besides yourself you need to cater for their 
 requirements.

I'd bet that most of the people looking at D's "filtering even numbers" 
example over at ( https://gist.github.com/817504 ) are thinking, "WTF is 
'iota'?"  (Either that or "What the hell is he converting to ASCII for?")

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

On 2/11/11 7:07 AM, foobar wrote:
 Andrei Alexandrescu Wrote:

 I don't find the name "iota" stupid.

 Andrei

 Of course _you_ don't. However practically all the users _do_ find it
 poorly named, including other developers in the project.. This is the
 umpteenth time this comes up in the NG and incidentally this is the
 only reason I know what the function does.

 If the users think the name is stupid than it really is. That's how
 usability works and the fact the you think otherwise or that it might
 be more accurate mathematically is really not relevant. If you want
 D/Phobos to be used by other people besides yourself you need to
 cater for their requirements.

Not all users dislike iota, and besides arguments ad populum are 
fallacious. Iota rocks. But have at it - vote away, and I'll be glad if 
a better name for iota comes about.

Andrei

so <so so.so> writes:

 Not all users dislike iota, and besides arguments ad populum are  
 fallacious. Iota rocks. But have at it - vote away, and I'll be glad if  
 a better name for iota comes about.

 Andrei

You asked for it!

atob(1, 6) // easy to mix things like atoi
ptoq(1, 6) // rocks imo!

so <so so.so> writes:

 atob(1, 6) // easy to mix things like atoi
 ptoq(1, 6) // rocks imo!

walk(1, 6) // now you have admit this is the best.

Daniel Gibson <metalcaedes gmail.com> writes:

Am 12.02.2011 01:46, schrieb so:
 atob(1, 6) // easy to mix things like atoi
 ptoq(1, 6) // rocks imo!

 
 walk(1, 6) // now you have admit this is the best.

Hmm I do kind of like it.

spir <denis.spir gmail.com> writes:

On 02/12/2011 01:46 AM, so wrote:
 atob(1, 6) // easy to mix things like atoi
 ptoq(1, 6) // rocks imo!

 walk(1, 6) // now you have admit this is the best.

Not bad, after all walk is a series of steps ;-)

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

Christopher Nicholson-Sauls <ibisbasenji gmail.com> writes:

On 02/11/11 18:46, so wrote:
 atob(1, 6) // easy to mix things like atoi
 ptoq(1, 6) // rocks imo!

 
 walk(1, 6) // now you have admit this is the best.

I dunno.  When I see 'walk' I think of collections, not ranges.  But...
I don't think it'd be terribly ambiguous, at least.

For the record... I "get" the iota name... and I don't buy the
eye-ambiguity with itoa.  We should be using to!string, yes?  But I'd be
happy to see a more descriptive name, so keep at it.

-- Chris N-S

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

On 2/12/11 3:59 AM, Christopher Nicholson-Sauls wrote:
 On 02/11/11 18:46, so wrote:
 atob(1, 6) // easy to mix things like atoi
 ptoq(1, 6) // rocks imo!

 walk(1, 6) // now you have admit this is the best.

 I dunno.  When I see 'walk' I think of collections, not ranges.  But...
 I don't think it'd be terribly ambiguous, at least.

 For the record... I "get" the iota name... and I don't buy the
 eye-ambiguity with itoa.  We should be using to!string, yes?  But I'd be
 happy to see a more descriptive name, so keep at it.

 -- Chris N-S

Look how iota fans are coming out of the woodwork! :o)

Andrei

spir <denis.spir gmail.com> writes:

On 02/12/2011 01:26 AM, so wrote:
 Not all users dislike iota, and besides arguments ad populum are fallacious.
 Iota rocks. But have at it - vote away, and I'll be glad if a better name for
 iota comes about.

 Andrei

 You asked for it!

 atob(1, 6) // easy to mix things like atoi
 ptoq(1, 6) // rocks imo!

     alias retro!iota atoi;

Actually, I like the term iota very much; would enjoy finding a good use for 
it. Something related to tolerance interval, for instance, like in production 
of mechanical parts. Really fits the notion of "a difference small enough to 
make no difference".

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

spir <denis.spir gmail.com> writes:

On 02/12/2011 12:55 AM, Andrei Alexandrescu wrote:
 Not all users dislike iota, and besides arguments ad populum are fallacious.
 Iota rocks. But have at it - vote away, and I'll be glad if a better name for
 iota comes about.

Proposed "interval" (which I understand as a quasi-synonym of range, apart from 
D's use of the term). 1-2 more people seemed to find it appropriate. Bearophile 
argued interval is ok but too long for such a common (?)(*) feature. What do 
you think?

Denis

(*) The notion is indeed somewhat common in code, but we have i..j for the most 
common cases, by far. iota() is only for when we need an assignable value 
representing an interval.
-- 
_________________
vita es estrany
spir.wikidot.com

bearophile <bearophileHUGS lycos.com> writes:

Andrei:

 Not all users dislike iota,

A poll will tell how much this statement is true :-)


 and besides arguments ad populum are fallacious.

That's true for scientific and engineering (or medical, etc) things but names
are not a science. The process of choosing names is part of ergonomics, it must
deal with what people, with what they find closer to their mind, culture,
brain. Python developers discuss carefully about naming, and indeed, Python
names are sometimes better than Phobos ones. One of the problems here is that
the mind of every person, you, me, Walter's has "quirks", that is mind
processes not shared by most other people. So if a single person chooses names,
those quirks come out, and the names are uniform (because they are chosen using
the same strategy, and this is positive), but sometimes they also reflect those
quirks. The only way I know to avoid this problem is to design names using
polls :-)


 Iota rocks. But have at it - vote away, and I'll be glad if 
 a better name for iota comes about.

I am not going to invent a new wonderful name for it, sorry :-) My votes, in
decreasing order of preference:
1) By far, a syntax like a..b:c, or missing that, a syntax like a..b
2) If first class interval syntax is really not possible, then my second choice
is a function named "range". This is what Python uses, it's natural, short
enough, and good.
3) If you refuse the word "range", then my third choice is "interval". It's as
cleas as range, but it's a bit worse because it's longer.
4) My fourth choice is "iota". It's short and it sticks in mind.

Bye,
bearophile

Michel Fortin <michel.fortin michelf.com> writes:

On 2011-02-11 19:55:05 -0500, bearophile <bearophileHUGS lycos.com> said:

 I am not going to invent a new wonderful name for it, sorry :-) My 
 votes, in decreasing order of preference:
 1) By far, a syntax like a..b:c, or missing that, a syntax like a..b

No one noticed yet that the a..b:c syntax causes ambiguity? Tell me, 
how do you rewrite this using the new proposed syntax:

	auto aa = [iota(a, b, c): 1, iota(d, e): 2];


 3) If you refuse the word "range", then my third choice is "interval". 
 It's as cleas as range, but it's a bit worse because it's longer.

Interval is clear only as long as there's no step value mentioned. 
Having a step value is quite a stretch from the usual notion of an 
interval.

I like a lot so's suggestion "walk". I'm not sure it's much clearer 
than iota though.

-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/

bearophile <bearophileHUGS lycos.com> writes:

Michel Fortin:

 No one noticed yet that the a..b:c syntax causes ambiguity? Tell me, 
 how do you rewrite this using the new proposed syntax:
 
 	auto aa = [iota(a, b, c): 1, iota(d, e): 2];

Right, that's why in another post I have said that syntax replaces most iota
usages. There are some situations where you can't use it well. This is another
situation I've shown in the enhancement request:
iota(10.,20.)
Writing it like this is not sane:
 10...20.


 Interval is clear only as long as there's no step value mentioned. 
 Having a step value is quite a stretch from the usual notion of an 
 interval.

Right, but I think it's acceptable still, and better than iota.


 I like a lot so's suggestion "walk". I'm not sure it's much clearer 
 than iota though.

It's better than iota, but not by much.

Bye,
bearophile

Daniel Gibson <metalcaedes gmail.com> writes:

Am 12.02.2011 02:25, schrieb bearophile:
 Michel Fortin:
 
 No one noticed yet that the a..b:c syntax causes ambiguity? Tell me, 
 how do you rewrite this using the new proposed syntax:

 	auto aa = [iota(a, b, c): 1, iota(d, e): 2];

 
 Right, that's why in another post I have said that syntax replaces most iota
usages. There are some situations where you can't use it well. This is another
situation I've shown in the enhancement request:
 iota(10.,20.)
 Writing it like this is not sane:
  10...20.
 
 
 Interval is clear only as long as there's no step value mentioned. 
 Having a step value is quite a stretch from the usual notion of an 
 interval.

 
 Right, but I think it's acceptable still, and better than iota.
 
 
 I like a lot so's suggestion "walk". I'm not sure it's much clearer 
 than iota though.

 
 It's better than iota, but not by much.
 
 Bye,
 bearophile

I think it's much better. Even having "steps" (or a stepsize) is obvious with
walk.

iota only makes sense when you know this from other languages/libraries or if
your native spoken language has a similar word that can be somehow connected.
http://en.wiktionary.org/wiki/iota doesn't give a real connection (and two
English->German dictionaries I've checked don't either - one only listed iota as
the greek letter, the other had mentions about something tiny) - it's just
something small like that greek i-without-a-dot letter.
There's nothing that connects it to a range of values with a fixed step size.

Cheers,
- Daniel

spir <denis.spir gmail.com> writes:

On 02/12/2011 02:36 AM, Daniel Gibson wrote:
 Am 12.02.2011 02:25, schrieb bearophile:
 Michel Fortin:

 No one noticed yet that the a..b:c syntax causes ambiguity? Tell me,
 how do you rewrite this using the new proposed syntax:

 	auto aa = [iota(a, b, c): 1, iota(d, e): 2];

 Right, that's why in another post I have said that syntax replaces most iota
usages. There are some situations where you can't use it well. This is another
situation I've shown in the enhancement request:
 iota(10.,20.)
 Writing it like this is not sane:
   10...20.


 Interval is clear only as long as there's no step value mentioned.
 Having a step value is quite a stretch from the usual notion of an
 interval.

 Right, but I think it's acceptable still, and better than iota.


 I like a lot so's suggestion "walk". I'm not sure it's much clearer
 than iota though.

 It's better than iota, but not by much.

 Bye,
 bearophile

 I think it's much better. Even having "steps" (or a stepsize) is obvious with
walk.

 iota only makes sense when you know this from other languages/libraries or if
 your native spoken language has a similar word that can be somehow connected.
 http://en.wiktionary.org/wiki/iota doesn't give a real connection (and two
 English->German dictionaries I've checked don't either - one only listed iota
as
 the greek letter, the other had mentions about something tiny) - it's just
 something small like that greek i-without-a-dot letter.
 There's nothing that connects it to a range of values with a fixed step size.

That page looks listing various meanings in foreign languages, but mostly 
stincks with the greek letter; it does not mention any sense everday sense iota 
actually has. Example fro fr.wiktionary:


Équivalent du i latin.


Free translation: little negligible quantity, nearly nothing.
There are good chances iota has a similar meaning in numerous languages, 
especially romance ones. Bearophile, Andrei?

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

Daniel Gibson <metalcaedes gmail.com> writes:

Am 12.02.2011 04:49, schrieb spir:
 On 02/12/2011 02:36 AM, Daniel Gibson wrote:
 Am 12.02.2011 02:25, schrieb bearophile:
 Michel Fortin:

 No one noticed yet that the a..b:c syntax causes ambiguity? Tell me,
 how do you rewrite this using the new proposed syntax:

     auto aa = [iota(a, b, c): 1, iota(d, e): 2];

 Right, that's why in another post I have said that syntax replaces most iota
 usages. There are some situations where you can't use it well. This is
 another situation I've shown in the enhancement request:
 iota(10.,20.)
 Writing it like this is not sane:
   10...20.


 Interval is clear only as long as there's no step value mentioned.
 Having a step value is quite a stretch from the usual notion of an
 interval.

 Right, but I think it's acceptable still, and better than iota.


 I like a lot so's suggestion "walk". I'm not sure it's much clearer
 than iota though.

 It's better than iota, but not by much.

 Bye,
 bearophile

 I think it's much better. Even having "steps" (or a stepsize) is obvious with
 walk.

 iota only makes sense when you know this from other languages/libraries or if
 your native spoken language has a similar word that can be somehow connected.
 http://en.wiktionary.org/wiki/iota doesn't give a real connection (and two
 English->German dictionaries I've checked don't either - one only listed iota
as
 the greek letter, the other had mentions about something tiny) - it's just
 something small like that greek i-without-a-dot letter.
 There's nothing that connects it to a range of values with a fixed step size.

 
 That page looks listing various meanings in foreign languages, but mostly
 stincks with the greek letter; it does not mention any sense everday sense iota
 actually has. Example fro fr.wiktionary:
 

 Équivalent du i latin.

 
 Free translation: little negligible quantity, nearly nothing.
 There are good chances iota has a similar meaning in numerous languages,
 especially romance ones. Bearophile, Andrei?
 
 Denis

I don't think a iota representing something small is too helpful.
iota() produces a (possibly very long) range of values with a possibly huge step
size (but even with a fixed step size of one it wouldn't make much sense to me).

Cheers,
- Daniel

Christopher Nicholson-Sauls <ibisbasenji gmail.com> writes:

On 02/11/11 19:36, Daniel Gibson wrote:
 Am 12.02.2011 02:25, schrieb bearophile:
 Michel Fortin:

 No one noticed yet that the a..b:c syntax causes ambiguity? Tell me, 
 how do you rewrite this using the new proposed syntax:

 	auto aa = [iota(a, b, c): 1, iota(d, e): 2];

 Right, that's why in another post I have said that syntax replaces most iota
usages. There are some situations where you can't use it well. This is another
situation I've shown in the enhancement request:
 iota(10.,20.)
 Writing it like this is not sane:
  10...20.


 Interval is clear only as long as there's no step value mentioned. 
 Having a step value is quite a stretch from the usual notion of an 
 interval.

 Right, but I think it's acceptable still, and better than iota.


 I like a lot so's suggestion "walk". I'm not sure it's much clearer 
 than iota though.

 It's better than iota, but not by much.

 Bye,
 bearophile

 
 I think it's much better. Even having "steps" (or a stepsize) is obvious with
walk.
 
 iota only makes sense when you know this from other languages/libraries or if
 your native spoken language has a similar word that can be somehow connected.
 http://en.wiktionary.org/wiki/iota doesn't give a real connection (and two
 English->German dictionaries I've checked don't either - one only listed iota
as
 the greek letter, the other had mentions about something tiny) - it's just
 something small like that greek i-without-a-dot letter.
 There's nothing that connects it to a range of values with a fixed step size.
 
 Cheers,
 - Daniel

We have a related usage around here, but it's probably a local thing
(western Kentucky).  I grew up hearing "iota" as a word for the
shortest/smallest distance/difference between two things, or
(indirectly) the frequency of a thing.

Not really an argument in favor of the name, mind you; but the usage had
to originate from *somewhere* and so I submit that it has probably never
been "official" but yet common at various times and places.

-- Chris N-S

spir <denis.spir gmail.com> writes:

On 02/12/2011 04:49 AM, spir wrote:
 That page looks listing various meanings in foreign languages, but mostly
 stincks with the greek letter; it does not mention any sense everday sense iota
 actually has. Example fro fr.wiktionary:

Oops, sorry for that noise, Denis
-- 
_________________
vita es estrany
spir.wikidot.com

Jacob Carlborg <doob me.com> writes:

On 2011-02-12 02:25, bearophile wrote:
 Michel Fortin:

 No one noticed yet that the a..b:c syntax causes ambiguity? Tell me,
 how do you rewrite this using the new proposed syntax:

 	auto aa = [iota(a, b, c): 1, iota(d, e): 2];

 Right, that's why in another post I have said that syntax replaces most iota
usages. There are some situations where you can't use it well. This is another
situation I've shown in the enhancement request:
 iota(10.,20.)
 Writing it like this is not sane:
   10...20.

Why can't we just get rid of that floating point literal syntax, it just 
causes problem.

 Interval is clear only as long as there's no step value mentioned.
 Having a step value is quite a stretch from the usual notion of an
 interval.

 Right, but I think it's acceptable still, and better than iota.


 I like a lot so's suggestion "walk". I'm not sure it's much clearer
 than iota though.

 It's better than iota, but not by much.

 Bye,
 bearophile


-- 
/Jacob Carlborg

bearophile <bearophileHUGS lycos.com> writes:

Jacob Carlborg:

 Why can't we just get rid of that floating point literal syntax, it just 
 causes problem.

I agree, the interval syntax (with or without optional stride) may be allowed
for integral values only.

(Elsewhere I have even suggested to disallow number literals like 1. or .1 :-) )

Bye,
bearophile

Jacob Carlborg <doob me.com> writes:

On 2011-02-12 18:18, bearophile wrote:
 Jacob Carlborg:

 Why can't we just get rid of that floating point literal syntax, it just
 causes problem.

 I agree, the interval syntax (with or without optional stride) may be allowed
for integral values only.

 (Elsewhere I have even suggested to disallow number literals like 1. or .1 :-)
)

I was actually referring to this.

 Bye,
 bearophile


-- 
/Jacob Carlborg

"Nick Sabalausky" <a a.a> writes:

"Jacob Carlborg" <doob me.com> wrote in message 
news:ij6emq$27so$2 digitalmars.com...
 On 2011-02-12 02:25, bearophile wrote:
 Michel Fortin:

 No one noticed yet that the a..b:c syntax causes ambiguity? Tell me,
 how do you rewrite this using the new proposed syntax:

 auto aa = [iota(a, b, c): 1, iota(d, e): 2];

 Right, that's why in another post I have said that syntax replaces most 
 iota usages. There are some situations where you can't use it well. This 
 is another situation I've shown in the enhancement request:
 iota(10.,20.)
 Writing it like this is not sane:
   10...20.

 Why can't we just get rid of that floating point literal syntax, it just 
 causes problem.

It's another one of those things, like octal literals, that are there just 
because Walter likes it.

Jonathan M Davis <jmdavisProg gmx.com> writes:

On Friday, February 11, 2011 17:02:18 Michel Fortin wrote:
 On 2011-02-11 19:55:05 -0500, bearophile <bearophileHUGS lycos.com> said:
 I am not going to invent a new wonderful name for it, sorry :-) My
 votes, in decreasing order of preference:
 1) By far, a syntax like a..b:c, or missing that, a syntax like a..b

 
 No one noticed yet that the a..b:c syntax causes ambiguity? Tell me,
 how do you rewrite this using the new proposed syntax:
 
 	auto aa = [iota(a, b, c): 1, iota(d, e): 2];
 
 3) If you refuse the word "range", then my third choice is "interval".
 It's as cleas as range, but it's a bit worse because it's longer.

 
 Interval is clear only as long as there's no step value mentioned.
 Having a step value is quite a stretch from the usual notion of an
 interval.
 
 I like a lot so's suggestion "walk". I'm not sure it's much clearer
 than iota though.

Honestly, I'd prefer iota to walk or interval. I see walk and I think about 
walkLength. It certainly isn't enough to tell me what the function does. 
interval is slightly better, but as you mention, the step value muddles that 
abstraction. While iota isn't clear, it _does_ have the advantage that you're 
not going to _mis_understand what it does based on its name, and it is _highly_ 
memorable. It's also short, which is nice. genSequence is pretty much the only 
thing that I've been able to think of that I like at all, but I'm perfectly
fine 
with keeping iota, honestly. It's short, and I'll actually remember it, even if 
I don't use it all of the time.

The thing about this kind of voting though is that it's likely that all of the 
folks who dislike the status quo will comment/complain and vote, whereas the 
people who don't really care or who actually really like the status quo mostly 
probably already stop reading this thread and won't say anything. So, it will 
look like the consensus is that the status quo is bad even if the majority 
actually don't agree. So, if we want to actually vote on this, then we should 
come up with a set of suggestions for the name and then start a new thread vote 
the vote. Personally, I'd just as soon leave iota as-is.

- Jonathan M Davis

bearophile <bearophileHUGS lycos.com> writes:

Jonathan M Davis:

 interval is slightly better, but as you mention, the step value muddles that 
 abstraction.

It's not muddled enough to make it worse than iota(). "iota" has nearly no
relation with its purpose in Phobos.


 genSequence is pretty much the only 
 thing that I've been able to think of that I like at all,

sequence(10,20,2) is another option, as long as "interval".


 So, if we want to actually vote on this, then we should 
 come up with a set of suggestions for the name and then start a new thread
vote 
 the vote.

I agree, in such things you need a two step process, as in brainstorming a
phase of inflation and ideas creation, followed by the phase phase of critical
thinking and choice.

Bye,
bearphile

spir <denis.spir gmail.com> writes:

On 02/12/2011 12:02 PM, bearophile wrote:
 genSequence is pretty much the only
  thing that I've been able to think of that I like at all,


 sequence(10,20,2) is another option, as long as "interval".

Know what? I've been thinking for a while that "sequence" would be quite a good 
name for D ranges. Including lazy "on-demand-generated" ones (like maps), 
infinite ones (cubes of natural ints), and plain views (D slices, reversed, 
every third item, filters in general...).
Then one "traverses" a sequence (= iteration) just like an in-memory 
collection. And/or traversal of in-memory collection actually happens via a 
(possibly implicite) standard sequence of the collection.

  So, if we want to actually vote on this, then we should
  come up with a set of suggestions for the name and then start a new thread
vote
  the vote.


 I agree, in such things you need a two step process, as in brainstorming a
phase of inflation and ideas creation, followed by the phase phase of critical
thinking and choice.



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

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

On 2/12/11 5:02 AM, bearophile wrote:
 Jonathan M Davis:

 interval is slightly better, but as you mention, the step value muddles that
 abstraction.

 It's not muddled enough to make it worse than iota(). "iota" has nearly no
relation with its purpose in Phobos.

And that's part of what makes it best.

Andrei

bearophile <bearophileHUGS lycos.com> writes:

Andrei:

 It's not muddled enough to make it worse than iota(). "iota" has nearly no
relation with its purpose in Phobos.

 
 And that's part of what makes it best.

To design APIs for other people you have to understand why this is awfully
wrong.

Bye,
bearophile

spir <denis.spir gmail.com> writes:

On 02/12/2011 12:25 PM, Andrei Alexandrescu wrote:
 On 2/12/11 5:02 AM, bearophile wrote:
 Jonathan M Davis:

 interval is slightly better, but as you mention, the step value muddles that
 abstraction.

 It's not muddled enough to make it worse than iota(). "iota" has nearly no
 relation with its purpose in Phobos.

 And that's part of what makes it best.

What about a random name generator to define a language.stdlib's lexicon? Then 
run a post-filter fed by user complaints about given names actually suggesting 
some relation to any [part|aspect] of their sense.

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

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

On 2/12/11 6:52 AM, spir wrote:
 On 02/12/2011 12:25 PM, Andrei Alexandrescu wrote:
 On 2/12/11 5:02 AM, bearophile wrote:
 Jonathan M Davis:

 interval is slightly better, but as you mention, the step value
 muddles that
 abstraction.

 It's not muddled enough to make it worse than iota(). "iota" has
 nearly no
 relation with its purpose in Phobos.

 And that's part of what makes it best.

 What about a random name generator to define a language.stdlib's
 lexicon? Then run a post-filter fed by user complaints about given names
 actually suggesting some relation to any [part|aspect] of their sense.

 denis

What I meant was that "iota" is not confusable with other concepts in 
Phobos, while at the same time being evocative for the task at hand. 
Another evocative term would be "quanta", but somehow I suspect that 
will enjoy little traction. :o)

Andrei

spir <denis.spir gmail.com> writes:

On 02/12/2011 02:05 PM, Andrei Alexandrescu wrote:
 On 2/12/11 6:52 AM, spir wrote:
 On 02/12/2011 12:25 PM, Andrei Alexandrescu wrote:
 On 2/12/11 5:02 AM, bearophile wrote:
 Jonathan M Davis:

 interval is slightly better, but as you mention, the step value
 muddles that
 abstraction.

 It's not muddled enough to make it worse than iota(). "iota" has
 nearly no
 relation with its purpose in Phobos.

 And that's part of what makes it best.

 What about a random name generator to define a language.stdlib's
 lexicon? Then run a post-filter fed by user complaints about given names
 actually suggesting some relation to any [part|aspect] of their sense.

 denis

 What I meant was that "iota" is not confusable with other concepts in Phobos,
 while at the same time being evocative for the task at hand. Another evocative
 term would be "quanta", but somehow I suspect that will enjoy little traction.
:o)

Sorry for the somewhat humourous (?) reply above. Your statement shocked me a 
bit (quite the opposite of what i think is good in design --for public use).
Now, I very much agree that <"iota" is not confusable with other concepts in 
Phobos> is a very good property.
And to clore my participation to this debate: I would not mind "iota" to 
remain, anyway not everyday use feature. But I think it's good we have 
discussed this point at length, for other features, present & future. "On the 
importance of proper naming." (for others' benefit)

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

Jonathan M Davis <jmdavisProg gmx.com> writes:

On Saturday 12 February 2011 03:25:29 Andrei Alexandrescu wrote:
 On 2/12/11 5:02 AM, bearophile wrote:
 Jonathan M Davis:
 interval is slightly better, but as you mention, the step value muddles
 that abstraction.

 
 It's not muddled enough to make it worse than iota(). "iota" has nearly
 no relation with its purpose in Phobos.

 
 And that's part of what makes it best.

Agreed.

- Jonathan M Davis

bearophile <bearophileHUGS lycos.com> writes:

Jonathan M Davis:

 On Saturday 12 February 2011 03:25:29 Andrei Alexandrescu wrote:
 And that's part of what makes it best.

 
 Agreed.

If you agree on that, then you can't be a designer for a public API.

Bye,
bearophile

Andrej Mitrovic <andrej.mitrovich gmail.com> writes:

Nonsense is the part of what makes it best? This one goes in my
favorite quotes bin.

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

On 2/12/11 8:40 AM, Andrej Mitrovic wrote:
 Nonsense is the part of what makes it best? This one goes in my
 favorite quotes bin.

Better put it in that bin with quotes taken out of context.

Andrei

Jonathan M Davis <jmdavisProg gmx.com> writes:

On Saturday 12 February 2011 06:21:15 bearophile wrote:
 Jonathan M Davis:
 On Saturday 12 February 2011 03:25:29 Andrei Alexandrescu wrote:
 And that's part of what makes it best.

 
 Agreed.

 
 If you agree on that, then you can't be a designer for a public API.

I'm not saying that you should typically pick function names that way. But
given 
that we already have iota, have already had iota for some time, and that there 
is already a C++ function by the same name that does the same thing, I see no 
reason to change it. It's nice and memorable, and it doesn't create confusion 
based on misunderstanding its name. Sure, a name that clearly says what it does 
would be nice, but I don't really like any of the names that have been 
suggested, and iota has worked just fine thus far.

I'm not suggesting that we go and name functions sigma and gamma or xyzzy or 
whatnot just because they mean nothing and are memorable. I'm saying that 
because we already have a function name which is memorable, I see no reason to 
exchange for one less memorable just because the name is nonsensical. It's 
useful in well-used functions to have short, memorable names, and iota fits
that 
to a t.

- Jonathan M Davis

Max Samukha <maxsamukha spambox.com> writes:

On 02/12/2011 04:52 PM, Jonathan M Davis wrote:
 On Saturday 12 February 2011 06:21:15 bearophile wrote:
 Jonathan M Davis:
 On Saturday 12 February 2011 03:25:29 Andrei Alexandrescu wrote:
 And that's part of what makes it best.

 Agreed.

 If you agree on that, then you can't be a designer for a public API.

 I'm not saying that you should typically pick function names that way. But
given
 that we already have iota, have already had iota for some time, and that there
 is already a C++ function by the same name that does the same thing, I see no
 reason to change it. It's nice and memorable, and it doesn't create confusion
 based on misunderstanding its name. Sure, a name that clearly says what it does
 would be nice, but I don't really like any of the names that have been
 suggested, and iota has worked just fine thus far.

Andrei's minion in me is feeling the urge to add that "iota" is also 
used in Go (for generating consecutive integers at compile-time, 
http://golang.org/doc/go_spec.html#Iota), and since Go is supposed to 
grow popular, "iota" will gain more popularity as well.

 I'm not suggesting that we go and name functions sigma and gamma or xyzzy or
 whatnot just because they mean nothing and are memorable. I'm saying that
 because we already have a function name which is memorable, I see no reason to
 exchange for one less memorable just because the name is nonsensical. It's
 useful in well-used functions to have short, memorable names, and iota fits
that
 to a t.

 - Jonathan M Davis

retard <re tard.com.invalid> writes:

Sat, 12 Feb 2011 17:54:24 +0200, Max Samukha wrote:

 On 02/12/2011 04:52 PM, Jonathan M Davis wrote:
 On Saturday 12 February 2011 06:21:15 bearophile wrote:
 Jonathan M Davis:
 On Saturday 12 February 2011 03:25:29 Andrei Alexandrescu wrote:
 And that's part of what makes it best.

 Agreed.

 If you agree on that, then you can't be a designer for a public API.

 I'm not saying that you should typically pick function names that way.
 But given that we already have iota, have already had iota for some
 time, and that there is already a C++ function by the same name that
 does the same thing, I see no reason to change it. It's nice and
 memorable, and it doesn't create confusion based on misunderstanding
 its name. Sure, a name that clearly says what it does would be nice,
 but I don't really like any of the names that have been suggested, and
 iota has worked just fine thus far.

 
 Andrei's minion in me is feeling the urge to add that "iota" is also
 used in Go (for generating consecutive integers at compile-time,
 http://golang.org/doc/go_spec.html#Iota), and since Go is supposed to
 grow popular, "iota" will gain more popularity as well.

You're just arguing against his principles:

"..besides arguments ad populum are fallacious"

http://www.digitalmars.com/webnews/newsgroups.php?
art_group=digitalmars.D&article_id=129453

Max Samukha <maxsamukha spambox.com> writes:

On 02/12/2011 07:12 PM, retard wrote:
 You're just arguing against his principles:

 "..besides arguments ad populum are fallacious"

 http://www.digitalmars.com/webnews/newsgroups.php?
 art_group=digitalmars.D&article_id=129453

Yes, I use ad populum all the time for its effectiveness.

I'll try to wriggle out by saying it was not an argument for "iota" but 
rather counterargument to the ad populum argument that "iota" is bad 
since it exists only in the long-forgotten APL and an unknown C++ extension.

retard <re tard.com.invalid> writes:

Sat, 12 Feb 2011 19:42:59 +0200, Max Samukha wrote:

 On 02/12/2011 07:12 PM, retard wrote:
 You're just arguing against his principles:

 "..besides arguments ad populum are fallacious"

 http://www.digitalmars.com/webnews/newsgroups.php?
 art_group=digitalmars.D&article_id=129453

 Yes, I use ad populum all the time for its effectiveness.
 
 I'll try to wriggle out by saying it was not an argument for "iota" but
 rather counterargument to the ad populum argument that "iota" is bad
 since it exists only in the long-forgotten APL and an unknown C++
 extension.

I can't deny facts. Iota is indeed quite widespread. I've seen it in 
several languages. However programming languages are like DNA. Even bad 
syntax sometimes gets in and becomes hard to remove.

Just a day or two ago bearophile showed how the octal literal syntax is 
harmful. But what happened is that it spread from C to C++, Java, and 
even Scala. Same can be said about the floating point literal syntax. Both 
1. and .1 are very minor improvements mainly for the laziest developers 
out there. It's getting harder and harder to get rid of them. Avoiding 
these kind of conflicts between core language features should be priority 

so <so so.so> writes:

 1. and .1 are very minor improvements mainly for the laziest developers
 out there. It's getting harder and harder to get rid of them. Avoiding
 these kind of conflicts between core language features should be priority


For lazy developers? i don't think so, how lazy one can get anyways, after  
all we are not typists.
We most of the time think (i can't be the judge here actually), rarely  
type.

I would love to see the reasoning on this one, and how successfully made  
it into most if not all languages.
Sometimes i think designers make this kind of decisions for their  
depressive times. In those times they remember this and laugh how they  
fooled the whole world.

retard <re tard.com.invalid> writes:

Sun, 13 Feb 2011 08:32:31 +0200, so wrote:

 1. and .1 are very minor improvements mainly for the laziest developers
 out there. It's getting harder and harder to get rid of them. Avoiding
 these kind of conflicts between core language features should be


 
 For lazy developers? i don't think so, how lazy one can get anyways,
 after all we are not typists.
 We most of the time think (i can't be the judge here actually), rarely
 type.
 
 I would love to see the reasoning on this one, and how successfully made
 it into most if not all languages.
 Sometimes i think designers make this kind of decisions for their
 depressive times. In those times they remember this and laugh how they
 fooled the whole world.

Might be :-D

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

On 2/12/11 8:21 AM, bearophile wrote:
 Jonathan M Davis:

 On Saturday 12 February 2011 03:25:29 Andrei Alexandrescu wrote:
 And that's part of what makes it best.

 Agreed.

 If you agree on that, then you can't be a designer for a public API.

Oops. Someone stop the release of 2.052 NOW! :o)

Andrei

Jonathan M Davis <jmdavisProg gmx.com> writes:

On Saturday 12 February 2011 07:34:43 Andrei Alexandrescu wrote:
 On 2/12/11 8:21 AM, bearophile wrote:
 Jonathan M Davis:
 On Saturday 12 February 2011 03:25:29 Andrei Alexandrescu wrote:
 And that's part of what makes it best.

 
 Agreed.

 
 If you agree on that, then you can't be a designer for a public API.

 
 Oops. Someone stop the release of 2.052 NOW! :o)

LOL. It would be true that I have now named a rather large portion of the 
functions in Phobos now thanks to std.datetime. However, those tend to have
very 
descriptive names. They also tended to be functions which were relatively easy 
to name.

Honestly, I never would have named iota iota. It isn't descriptive at all. But 
given that we already _have_ the name and there is a precedent for it, I see no 
reason to change it. It's short and memorable, and you're not going to 
misunderstand what it means based on its name.

So, no I wouldn't have chosen iota if I were naming it, but I don't think that 
it's worth breaking code for now. Since we have it, I say take advantage of the 
fact that it's short and memorable and just leave it.

- Jonathan M Davis

=?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:

Jonathan M Davis wrote:
 you're not going to misunderstand what it [iota] means based on its nam=

e.
=20

	Again, people *will* and actually, people *have* misunderstood it
based on its name.

		Jerome
--=20
mailto:jeberger free.fr
http://jeberger.free.fr
Jabber: jeberger jabber.fr

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

On 2/12/11 5:02 AM, bearophile wrote:
 Jonathan M Davis:

 interval is slightly better, but as you mention, the step value muddles that
 abstraction.

 It's not muddled enough to make it worse than iota(). "iota" has nearly no
relation with its purpose in Phobos.


 genSequence is pretty much the only
 thing that I've been able to think of that I like at all,

 sequence(10,20,2) is another option, as long as "interval".

Taken, see std.range.sequence.

Andrei

spir <denis.spir gmail.com> writes:

On 02/12/2011 03:05 AM, Jonathan M Davis wrote:
 While iota isn't clear, it _does_ have the advantage that you're
 not going to _mis_understand

Maybe you say this because iota does not mean anything for you (?). I can 
easily imagine various appropriate uses of iota in a PL, like:

* smallest representable value in a given numeric format
* threshold over which some measure should be taken into account
* threshold under which some difference should be ignored
* range for approximate equality (approxEquals: |x - y| < iota)
* tolerance interval of technical measures (similar)
* ...what else?

(I would be surprised if actual uses of iota in english do not point toward 
this kind of senses.)

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

=?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:

spir wrote:
 On 02/12/2011 03:05 AM, Jonathan M Davis wrote:
 While iota isn't clear, it _does_ have the advantage that you're
 not going to _mis_understand

=20
 Maybe you say this because iota does not mean anything for you (?). I
 can easily imagine various appropriate uses of iota in a PL, like:
=20
 * smallest representable value in a given numeric format
 * threshold over which some measure should be taken into account
 * threshold under which some difference should be ignored
 * range for approximate equality (approxEquals: |x - y| < iota)
 * tolerance interval of technical measures (similar)
 * ...what else?
=20

	Range with a single element (i.e the smallest non-empty range).
Which is actually how I interpreted =E2=80=9Ciota=E2=80=9D the first time=
 I saw it
(since it was obvious from the context that it was a range).

		Jerome
--=20
mailto:jeberger free.fr
http://jeberger.free.fr
Jabber: jeberger jabber.fr

spir <denis.spir gmail.com> writes:

On 02/12/2011 09:44 AM, "Jérôme M. Berger" wrote:
 spir wrote:
 On 02/12/2011 03:05 AM, Jonathan M Davis wrote:
 While iota isn't clear, it _does_ have the advantage that you're
 not going to _mis_understand

 Maybe you say this because iota does not mean anything for you (?). I
 can easily imagine various appropriate uses of iota in a PL, like:

 * smallest representable value in a given numeric format
 * threshold over which some measure should be taken into account
 * threshold under which some difference should be ignored
 * range for approximate equality (approxEquals: |x - y|<  iota)
 * tolerance interval of technical measures (similar)
 * ...what else?

 	Range with a single element (i.e the smallest non-empty range).
 Which is actually how I interpreted “iota” the first time I saw it
 (since it was obvious from the context that it was a range).

Makes sense for me as well.

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

spir <denis.spir gmail.com> writes:

On 02/12/2011 01:55 AM, bearophile wrote:
 4) My fourth choice is "iota". It's short and it sticks in mind.

'Ψ' "psi" (beeing the forelast letter of the alphabet, just before omega, as 
everyone knows) would nicely suggest we're dealing with intervals half-open on 
the right-hand side.

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

=?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:

spir wrote:
 On 02/12/2011 01:55 AM, bearophile wrote:
 4) My fourth choice is "iota". It's short and it sticks in mind.

=20
 '=CE=A8' "psi" (beeing the forelast letter of the alphabet, just before=

 omega, as everyone knows) would nicely suggest we're dealing with
 intervals half-open on the right-hand side.
=20

	Love that one! ;D

		Jerome
--=20
mailto:jeberger free.fr
http://jeberger.free.fr
Jabber: jeberger jabber.fr

Olivier Pisano <olivier.pisano laposte.net> writes:

Le 12/02/11 01:55, bearophile a �crit :
 Andrei:

 Not all users dislike iota,

 A poll will tell how much this statement is true :-)


 and besides arguments ad populum are fallacious.

 That's true for scientific and engineering (or medical, etc) things but names
are not a science. The process of choosing names is part of ergonomics, it must
deal with what people, with what they find closer to their mind, culture,
brain. Python developers discuss carefully about naming, and indeed, Python
names are sometimes better than Phobos ones. One of the problems here is that
the mind of every person, you, me, Walter's has "quirks", that is mind
processes not shared by most other people. So if a single person chooses names,
those quirks come out, and the names are uniform (because they are chosen using
the same strategy, and this is positive), but sometimes they also reflect those
quirks. The only way I know to avoid this problem is to design names using
polls :-)

I fully agree with you Bearophile.

 Iota rocks. But have at it - vote away, and I'll be glad if
 a better name for iota comes about.

 I am not going to invent a new wonderful name for it, sorry :-) My votes, in
decreasing order of preference:
 1) By far, a syntax like a..b:c, or missing that, a syntax like a..b
 2) If first class interval syntax is really not possible, then my second
choice is a function named "range". This is what Python uses, it's natural,
short enough, and good.
 3) If you refuse the word "range", then my third choice is "interval". It's as
cleas as range, but it's a bit worse because it's longer.
 4) My fourth choice is "iota". It's short and it sticks in mind.

I am certainly not a regular poster here, so my opinion is likely to be 
less taken into account, but as a simple D user whose primary language 
is not English, here is my humble contribution (FWIW) :

1) I'd like to have the a..b syntax.
2) I think I like "interval" the most. It is certainly longer than iota 
to write, but as code is certainly much more read than written, I think 
it is an acceptable tradeoff. I guess Phobos does already functions with 
names longer than 7 chars, doesn't it ?

If you take Andrei's example :

   filter!`a % 2 == 0`(iota(1, 5))

and

   filter!`a % 2 == 0`(interval(1, 5))

I believe the second is likely to be more informative in terms of what 
the function does to a newcoming user. Interval comes from latin and 
latin-derived languages are quite widespread around the world.

According to Google :
Spanish: intervalo
Portugese: intervalo
French: intervalle
Italian: intervallo
Romanian: interval

BTW, musical theory does use the same vocabulary (intervals and steps), 
it is certainly not a valid argument, but as music one of the most 
universal thing on this earth, I find it amusing.

3) I don't think "range" should be used here. I love it in Python, but 
Range does refer to a more generic concept in D. Using range as a 
function name could add some confusion.

4) I believe a function name should tell what it does. An alphabet 
letter (greek or not) is a poor indication and should be avoided. "sum" 
is a more reasonable choice than "epsilon", even if that what we all 
write in math.

My two cents,

Olivier

Olivier Pisano <olivier.pisano laposte.net> writes:

Le 12/02/11 10:36, Olivier Pisano a �crit :
 4) I believe a function name should tell what it does. An alphabet
 letter (greek or not) is a poor indication and should be avoided. "sum"
 is a more reasonable choice than "epsilon", even if that what we all
 write in math.


Damn fever, I meant Sigma, of course, not epsilon...

Christopher Nicholson-Sauls <ibisbasenji gmail.com> writes:

On 02/12/11 04:08, Olivier Pisano wrote:
 Le 12/02/11 10:36, Olivier Pisano a écrit :
 4) I believe a function name should tell what it does. An alphabet
 letter (greek or not) is a poor indication and should be avoided. "sum"
 is a more reasonable choice than "epsilon", even if that what we all
 write in math.

 
 
 Damn fever, I meant Sigma, of course, not epsilon...
 

Was gonna say... thought epsilon meant "nothing" which is quite apart
from "sum."  Either that, or we've just waxed existential in this
discussion.   __ 

-- Chris N-S

"Nick Sabalausky" <a a.a> writes:

"Olivier Pisano" <olivier.pisano laposte.net> wrote in message 
news:ij5mb2$spd$1 digitalmars.com...
 Le 12/02/11 10:36, Olivier Pisano a �crit :
 4) I believe a function name should tell what it does. An alphabet
 letter (greek or not) is a poor indication and should be avoided. "sum"
 is a more reasonable choice than "epsilon", even if that what we all
 write in math.


 Damn fever, I meant Sigma, of course, not epsilon...

Perfect example of why using letter names should be avoided! :)

Walter Bright <newshound2 digitalmars.com> writes:

Andrei Alexandrescu wrote:
 Not all users dislike iota, and besides arguments ad populum are 
 fallacious. Iota rocks. But have at it - vote away, and I'll be glad if 
 a better name for iota comes about.


delta

Andrej Mitrovic <andrej.mitrovich gmail.com> writes:

On 2/12/11, Walter Bright <newshound2 digitalmars.com> wrote:
 Andrei Alexandrescu wrote:
 Not all users dislike iota, and besides arguments ad populum are
 fallacious. Iota rocks. But have at it - vote away, and I'll be glad if
 a better name for iota comes about.


 delta

Now that's sexy. Makes me feel like a commander when coding D.

In fact, let me dust off my old C&C cd's, I'm in the mood for some RTS.

"Nick Sabalausky" <a a.a> writes:

"Andrej Mitrovic" <andrej.mitrovich gmail.com> wrote in message 
news:mailman.1524.1297475525.4748.digitalmars-d puremagic.com...
 On 2/12/11, Walter Bright <newshound2 digitalmars.com> wrote:
 Andrei Alexandrescu wrote:
 Not all users dislike iota, and besides arguments ad populum are
 fallacious. Iota rocks. But have at it - vote away, and I'll be glad if
 a better name for iota comes about.


 delta

 Now that's sexy. Makes me feel like a commander when coding D.

 In fact, let me dust off my old C&C cd's, I'm in the mood for some RTS.

I was just thinking Delta Force. Sniping 6-pixel-tall soldiers from across a 
voxel canyon == amazingly fantastic eye-straining fun :) Bravo team, do you 
read me?!?

Heh, speaking of great military fun:
http://unconventional-airsoft.com/2003/01/15/hand-signals-defined/

=?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:

Walter Bright wrote:
 Andrei Alexandrescu wrote:
 Not all users dislike iota, and besides arguments ad populum are
 fallacious. Iota rocks. But have at it - vote away, and I'll be glad
 if a better name for iota comes about.

=20
=20
 delta

	Could be, except that this is very often used as a variable name to
represent a difference.

		Jerome
--=20
mailto:jeberger free.fr
http://jeberger.free.fr
Jabber: jeberger jabber.fr

spir <denis.spir gmail.com> writes:

On 02/12/2011 02:40 AM, Walter Bright wrote:
 Andrei Alexandrescu wrote:
 Not all users dislike iota, and besides arguments ad populum are fallacious.
 Iota rocks. But have at it - vote away, and I'll be glad if a better name for
 iota comes about.


 delta

Like it, but for a single step (of arbitrary size, and direction). Misses the 
idea "series of..." I guess.

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

J Chapman <johnch_atms hotmail.com> writes:

series

spir <denis.spir gmail.com> writes:

On 02/12/2011 01:46 PM, J Chapman wrote:
 series

Unfortunately series in maths means the sum of a sequence (at least in F, but I 
bet the same applies in E). Rather evokes accum/reduce/fold (for people who 
think at the sense in maths).

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

Jacob Carlborg <doob me.com> writes:

On 2011-02-12 00:55, Andrei Alexandrescu wrote:
 On 2/11/11 7:07 AM, foobar wrote:
 Andrei Alexandrescu Wrote:

 I don't find the name "iota" stupid.

 Andrei

 Of course _you_ don't. However practically all the users _do_ find it
 poorly named, including other developers in the project.. This is the
 umpteenth time this comes up in the NG and incidentally this is the
 only reason I know what the function does.

 If the users think the name is stupid than it really is. That's how
 usability works and the fact the you think otherwise or that it might
 be more accurate mathematically is really not relevant. If you want
 D/Phobos to be used by other people besides yourself you need to
 cater for their requirements.

 Not all users dislike iota, and besides arguments ad populum are
 fallacious. Iota rocks. But have at it - vote away, and I'll be glad if
 a better name for iota comes about.

 Andrei

I vote:

1) 1 .. 4
2) range

If we ever get the uniform function call syntax in D then this could work:

1.upto(4)

-- 
/Jacob Carlborg

spir <denis.spir gmail.com> writes:

On 02/12/2011 06:02 PM, Jacob Carlborg wrote:
 On 2011-02-12 00:55, Andrei Alexandrescu wrote:
 On 2/11/11 7:07 AM, foobar wrote:
 Andrei Alexandrescu Wrote:

 I don't find the name "iota" stupid.

 Andrei

 Of course _you_ don't. However practically all the users _do_ find it
 poorly named, including other developers in the project.. This is the
 umpteenth time this comes up in the NG and incidentally this is the
 only reason I know what the function does.

 If the users think the name is stupid than it really is. That's how
 usability works and the fact the you think otherwise or that it might
 be more accurate mathematically is really not relevant. If you want
 D/Phobos to be used by other people besides yourself you need to
 cater for their requirements.

 Not all users dislike iota, and besides arguments ad populum are
 fallacious. Iota rocks. But have at it - vote away, and I'll be glad if
 a better name for iota comes about.

 Andrei

 I vote:

 1) 1 .. 4
 2) range

 If we ever get the uniform function call syntax in D then this could work:

 1.upto(4)

counter(1,9, 2)		// ?

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

Peter Alexander <peter.alexander.au gmail.com> writes:

On 11/02/11 11:55 PM, Andrei Alexandrescu wrote:
 Not all users dislike iota, and besides arguments ad populum are
 fallacious. Iota rocks. But have at it - vote away, and I'll be glad if
 a better name for iota comes about.

 Andrei

finiteArithmeticProgression :-)

Come on! It's the only name that's actually correct so far!

Seriously though, my list of preferences would be:

- Add a..b syntax, and something non-ambiguous for steps.
- iota(a, b, c), because it's short and has the same meaning elsewhere.
- step(a, b, c), again because it's short, but also meaningful

interval is bad because it doesn't imply a step.
range is bad because it already has a meaning in Phobos.
delta is bad because it means a difference, not a sequence.

"Nick Sabalausky" <a a.a> writes:

"Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
news:ij4iel$ig$2 digitalmars.com...
 On 2/11/11 7:07 AM, foobar wrote:
 Andrei Alexandrescu Wrote:

 I don't find the name "iota" stupid.

 Andrei

 Of course _you_ don't. However practically all the users _do_ find it
 poorly named, including other developers in the project.. This is the
 umpteenth time this comes up in the NG and incidentally this is the
 only reason I know what the function does.

 If the users think the name is stupid than it really is. That's how
 usability works and the fact the you think otherwise or that it might
 be more accurate mathematically is really not relevant. If you want
 D/Phobos to be used by other people besides yourself you need to
 cater for their requirements.

 Not all users dislike iota, and besides arguments ad populum are 
 fallacious. Iota rocks. But have at it - vote away, and I'll be glad if a 
 better name for iota comes about.

I vote "a..b:c" and "step"

Andrej Mitrovic <andrej.mitrovich gmail.com> writes:

I'd maybe vote for the syntax change.

But maybe we could extend the array slice syntax to construct ranges:

filter!`a % 2 == 0`([1..5])
auto r = [0 .. 5];

So if the slice sits on its own it becomes a range. Or is this too
scary/ambiguous?

I don't really like them alone:
filter!`a % 2 == 0`(1..5)
auto r = 0 .. 5;

Otherwise I'd probably vote for "walk", or if we can't settle as a
majority on a word I guess we'll just stick to iota and that will be
the end of it. I don't hate it but newbies will be confused with it.

But you're only a newbie once, right? :)

bearophile <bearophileHUGS lycos.com> writes:

Andrej Mitrovic:

 I'd maybe vote for the syntax change.
 
 But maybe we could extend the array slice syntax to construct ranges:
 
 filter!`a % 2 == 0`([1..5])
 auto r = [0 .. 5];
 
 So if the slice sits on its own it becomes a range. Or is this too
 scary/ambiguous?

In Python there are list comp. and iterators, so for me a syntax like [1..5]
means something like array(iota(1,5)) while 1..5 means something like
iota(1,5). 

Bye,
bearophile

"Nick Sabalausky" <a a.a> writes:

"Andrej Mitrovic" <andrej.mitrovich gmail.com> wrote in message 
news:mailman.1581.1297547851.4748.digitalmars-d puremagic.com...
 I'd maybe vote for the syntax change.

 But maybe we could extend the array slice syntax to construct ranges:

 filter!`a % 2 == 0`([1..5])
 auto r = [0 .. 5];

 So if the slice sits on its own it becomes a range. Or is this too
 scary/ambiguous?

I like that. It also avoids this ambiguity:

class Foo
{
    opSlice(int a, int b) {}
    opIndex(R)(R r) if(isSomeRange!R) {}
}

auto f = new Foo();
f[1..5] // opSlice with ints, or opIndex with a range?

If a..b requires [] to be a range literal, then the above is unambiguously 
an opSlice with ints, and calling opIndex with a range literal would be 
f[[1..5]].

Not sure why anyone would ever index on a range though, outside of operator 
overload abuse.

"Simen kjaeraas" <simen.kjaras gmail.com> writes:

Nick Sabalausky <a a.a> wrote:

 f[1..5] // opSlice with ints, or opIndex with a range?

This is also an interesting point. If a..b were to be a separate type,
opSlice would no longer need to exist, it could be a simple overload
of opIndex. This would easily enable multi-dimensional slicing, which
currently is impossible in D (barring tricks like using opIndex behind
the scenes and a struct with overloaded slicing to create the slice
indices: foo[ _[0..1], _[2..3] ];).

-- 
Simen

Peter Alexander <peter.alexander.au gmail.com> writes:

On 12/02/11 9:16 PM, Nick Sabalausky wrote:
 "Andrei Alexandrescu"<SeeWebsiteForEmail erdani.org>  wrote in message
 Not all users dislike iota, and besides arguments ad populum are
 fallacious. Iota rocks. But have at it - vote away, and I'll be glad if a
 better name for iota comes about.

 I vote "a..b:c" and "step"

As Michel pointed out, a..b:c is ambiguous.

auto foo = [ 1..10 : 2, 2..20 : 3 ];

Is foo an AA of ranges to ints, or an array of stepped ranges?

bearophile <bearophileHUGS lycos.com> writes:

Peter Alexander:

 As Michel pointed out, a..b:c is ambiguous.
 
 auto foo = [ 1..10 : 2, 2..20 : 3 ];
 
 Is foo an AA of ranges to ints, or an array of stepped ranges?

Lazy strided intervals as associative array keys is not a common need. But
there are few other situations:
auto r = pred ? 1..10 : 2 : 2..20 : 3;

Where the range syntax is not usable you may use the function from Phobos as
fall-back:
auto r = pred ? iota(1,10,2) : iota(2,20,3);

A possible alternative is to require parentheses where the syntax is ambiguous:
auto foo = [(1..10 : 2), (2..20 : 3)];
auto r = pred ? (1..10 : 2) : (2..20 : 3);

Another alternative is to use .. to separate the stride too:
auto foo = [1..10..2, 2..20..3];
auto r = pred ? 1..10..2 : 2..20..3;

In this post I have assumed that the interval syntax is usable on integral
values only. For floating point ones you use iota again:
iota(1.0, 10.0, 0.5)

Bye,
bearophile

Andrej Mitrovic <andrej.mitrovich gmail.com> writes:

On 2/12/11, Peter Alexander <peter.alexander.au gmail.com> wrote:
 On 12/02/11 9:16 PM, Nick Sabalausky wrote:
 "Andrei Alexandrescu"<SeeWebsiteForEmail erdani.org>  wrote in message
 Not all users dislike iota, and besides arguments ad populum are
 fallacious. Iota rocks. But have at it - vote away, and I'll be glad if a
 better name for iota comes about.

 I vote "a..b:c" and "step"

 As Michel pointed out, a..b:c is ambiguous.

 auto foo = [ 1..10 : 2, 2..20 : 3 ];

 Is foo an AA of ranges to ints, or an array of stepped ranges?

array of stepped ranges:
auto foo = [[1..10 : 2], [2..20 : 3]];
output:
[[1, 3, 5, 7, 9], [2, 5, 8, 11, 14, 17]]

AA of ranges to ints:
auto foo = [[1..10] : 2, [2..20] : 3];
output:
[1, 2, 3, 4, 5, 6, 7, 8, 9]:2
[2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19]:3


iota vs new syntax:

    auto iot1 = [iota(1,10,2), iota(2, 20, 3)];     // array
    auto iot2 = [iota(1,10) : 2, iota(2, 20) : 3];  // AA

    auto syn1 = [[1..10 : 2], [2..20 : 3]];    // array
    auto syn2 = [[1..10] : 2, [2..20] : 3];    // AA

Andrej Mitrovic <andrej.mitrovich gmail.com> writes:

But again, I don't know who uses ranges as keys to an AA. So my guess
is you would see this very rarely in code, so it's not a fair
comparison to iota. It does show that in this case there's no
ambiguity, unless I'm mistaken.

Andrej Mitrovic <andrej.mitrovich gmail.com> writes:

This would make more sense as a comparison:

    auto iot1 = [iota(0, 10, 2), iota(0, 10, 3)];
    auto iot2 = [2 : iota(0, 10, 2), 3 : iota(0, 10, 3)];

    auto syn1 = [[0..10 : 2], [0..10 : 3]];
    auto syn2 = [2: [0..10 : 2], 3: [0..10 : 3]];

    // iot1 == [[0, 2, 4, 6, 8], [0, 3, 6, 9]]
    // iot2 == 2:[0, 2, 4, 6, 8] 3:[0, 3, 6, 9]

    assert(iot1 == syn1);
    assert(iot2 == syn2);

Andrej Mitrovic <andrej.mitrovich gmail.com> writes:

    foreach (step; steps)
    {
        writeln( [iota(min, max, step), iota(min, max, step+1)] );
        writeln( [[min..max : step], [min..max : step+1]] );

        max += step;
    }

Sorry for spamming. :)

I'm getting more and more convinced to join the iota camp. The new
syntax barely saves any characters, and is potentially confusing.

spir <denis.spir gmail.com> writes:

On 02/12/2011 10:57 PM, Andrej Mitrovic wrote:
 I'd maybe vote for the syntax change.

 But maybe we could extend the array slice syntax to construct ranges:

 filter!`a % 2 == 0`([1..5])
 auto r = [0 .. 5];

 So if the slice sits on its own it becomes a range. Or is this too
 scary/ambiguous?

 I don't really like them alone:
 filter!`a % 2 == 0`(1..5)
 auto r = 0 .. 5;

I like your idea of [i..j] alone meaning interval. After all, that's exactly 
the sense, no? And
(1) it solves the issue of [i..j:step] ambiguity
(2) which may even extend to slices: array[1..$:3]
But it's inconsistent with
    foreach (n; i..j) {}
We should have had this syntax from the start, or we face a backward 
incompatible change.
I would vote for it, but only because I don't have a big D code base ;-)


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

Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:

On 11/02/2011 23:55, Andrei Alexandrescu wrote:
 On 2/11/11 7:07 AM, foobar wrote:
 Andrei Alexandrescu Wrote:

 I don't find the name "iota" stupid.

 Andrei




I want to make a few comments, arising from several different posts in 
this discussion.


First, before this discussion that Ary started, I had heard the "iota" 
function being mentioned a few times in other NG posts, and although I 
wasn't 100% sure of what it did, I did deduce it returned a sequence of 
numbers (in range API).
And also I assumed this number sequence was related to some concept in 
mathematics called iota (like a Fibonacci sequence, or the factors in a 
Taylor series, etc.). I found now that such is not the case, the term 
iota as used in D was introduced by the APL language, but is not defined 
or well-known in mathematics academia.



Generally speaking I agree with with Ary's idea of having better, more 
descriptive names. But I am not sure I agree what would be a better 
alternative.
I find the name "iota" to be meaningless, but "range" for example is 
worse because its meaning conflicts with the general meaning of D 
"ranges". Conflicts in the sense that although iota(...) does return a 
range, it does something quite more specific. I would rather introduce a 
new term ("iota"), than use a confusing or overlapping one like "range" 
(or even "interval").


I might prefer the function to be called "numberSequence" or 
"numberSeq", but I don't yet have a strong enough opinion to actually 
cast a vote.

-- 
Bruno Medeiros - Software Engineer

foobar <foo bar.com> writes:

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

Thanks for this, I'm adding this book to my read list. :)

Walter Bright <newshound2 digitalmars.com> writes:

foobar wrote:
 Ary Manzana Wrote:
 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.

 
 Thanks for this, I'm adding this book to my read list. :)


Every engineer and designer should read it. It's a classic, and a quick read.

The irony of it is, of course, everyone agrees with it, laughs at the stupid 
designs shown in the book, and then goes right out and create their own equally 
stupid designs.

Making designs that are intuitively obvious is amazingly difficult.

Jonathan M Davis <jmdavisProg gmx.com> writes:

On Friday 11 February 2011 20:01:23 spir wrote:
 On 02/12/2011 03:05 AM, Jonathan M Davis wrote:
 While iota isn't clear, it _does_ have the advantage that you're
 not going to _mis_understand

 
 Maybe you say this because iota does not mean anything for you (?). I can
 easily imagine various appropriate uses of iota in a PL, like:
 
 * smallest representable value in a given numeric format
 * threshold over which some measure should be taken into account
 * threshold under which some difference should be ignored
 * range for approximate equality (approxEquals: |x - y| < iota)
 * tolerance interval of technical measures (similar)
 * ...what else?
 
 (I would be surprised if actual uses of iota in english do not point toward
 this kind of senses.)

iota is almost entirely unused in English. You might say something like "that 
doesn't make an iota of sense," but it's pretty rare. And even if you do, it's 
an iota of _something_, so something like |x - y| < iota would be just plain 
weird. Regardless, iota would be a weird name to use for _anything_ when naming 
variables or functions. It just isn't used much in English. And there are
pretty 
much always going to be better names for the function or variable if you're 
trying to use iota for something similar to its actual meaning. If anyone tried 
to use iota to actually mean something as a variable or function name, I'd be 
suggesting that they pick a better nam.

- Jonathan M Davis

=?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:

Jonathan M Davis wrote:
 On Friday 11 February 2011 20:01:23 spir wrote:
 On 02/12/2011 03:05 AM, Jonathan M Davis wrote:
 While iota isn't clear, it _does_ have the advantage that you're
 not going to _mis_understand

 Maybe you say this because iota does not mean anything for you (?). I =


can
 easily imagine various appropriate uses of iota in a PL, like:

 * smallest representable value in a given numeric format
 * threshold over which some measure should be taken into account
 * threshold under which some difference should be ignored
 * range for approximate equality (approxEquals: |x - y| < iota)
 * tolerance interval of technical measures (similar)
 * ...what else?

 (I would be surprised if actual uses of iota in english do not point t=


oward
 this kind of senses.)

=20
 iota is almost entirely unused in English. You might say something like=

 "that=20
 doesn't make an iota of sense," but it's pretty rare. And even if you d=

o, it's=20
 an iota of _something_, so something like |x - y| < iota would be just =

plain=20
 weird. Regardless, iota would be a weird name to use for _anything_ whe=

n naming=20
 variables or functions. It just isn't used much in English. And there a=

re pretty=20
 much always going to be better names for the function or variable if yo=

u're=20
 trying to use iota for something similar to its actual meaning. If anyo=

ne tried=20
 to use iota to actually mean something as a variable or function name, =

I'd be=20
 suggesting that they pick a better nam.
=20

	It is used enough to make it into the Collins Cobuild dictionary,
which uses statistics on word occurrences to decide whether they
should be included. One of the examples they regard as typical is:
=E2=80=9CI don't think you've change an iota=E2=80=9D, which means more o=
r less
=E2=80=9C|new - old| < iota=E2=80=9D, so it is not that far fetched.

		Jerome
--=20
mailto:jeberger free.fr
http://jeberger.free.fr
Jabber: jeberger jabber.fr

Jeff Nowakowski <jeff dilacero.org> writes:

On 02/11/2011 11:14 PM, Jonathan M Davis wrote:
 If anyone tried to use iota to actually mean something as a variable
 or function name, I'd be suggesting that they pick a better nam.

So you're saying you don't like Andrei's chosen name? ;)

Jonathan M Davis <jmdavisProg gmx.com> writes:

On Saturday 12 February 2011 02:33:12 Jeff Nowakowski wrote:
 On 02/11/2011 11:14 PM, Jonathan M Davis wrote:
 If anyone tried to use iota to actually mean something as a variable
 or function name, I'd be suggesting that they pick a better nam.

 
 So you're saying you don't like Andrei's chosen name? ;)

No. Andrei isn't trying to use the word based on its actual meaning. As it 
stands, the name is essentially nonsensical. That means that it's a vey poor 
name from the standpoint of figuring out what the function does based on its 
name.

_However_, precisely because it's such a short and nonsensical name, it's
really 
easy to remember. I'm fine with keeping it as is. If someone could come up with
a 
perfect replacement, then that woludn't be too bad, but honestly, I think that 
most of the names suggested actually increase the confusion.

With iota, you don't have a clue what it does based on its name, so you look it 
up. Then you remember it, because it's very memborable. With something like
walk 
or interval, the name gives you a better idea of what it does, but it's _still_ 
not good enough for you to know based on the name and, since they mean
something 
closer to what the function actually does but not quite, they risk misleading 
you as to what the function does. At least with iota, you know that you're
going 
to have to look it up.

There's already precedent for iota as Andrei has stated, and it's been in 
std.algorithm for a while, so I'm fine with leaving it as is. It's a highly 
memborable name, and it's nice and short to boot.

- Jonathan M Davis

=?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:

Jonathan M Davis wrote:
 On Saturday 12 February 2011 02:33:12 Jeff Nowakowski wrote:
 On 02/11/2011 11:14 PM, Jonathan M Davis wrote:
 If anyone tried to use iota to actually mean something as a variable
 or function name, I'd be suggesting that they pick a better nam.

 So you're saying you don't like Andrei's chosen name? ;)

=20
 No. Andrei isn't trying to use the word based on its actual meaning. As=

 it=20
 stands, the name is essentially nonsensical. That means that it's a vey=

 poor=20
 name from the standpoint of figuring out what the function does based o=

n its=20
 name.
=20
 _However_, precisely because it's such a short and nonsensical name, it=

's really=20
 easy to remember. I'm fine with keeping it as is. If someone could come=

 up with a=20
 perfect replacement, then that woludn't be too bad, but honestly, I thi=

nk that=20
 most of the names suggested actually increase the confusion.
=20
 With iota, you don't have a clue what it does based on its name, so you=

 look it=20
 up. Then you remember it, because it's very memborable. With something =

like walk=20
 or interval, the name gives you a better idea of what it does, but it's=

 _still_=20
 not good enough for you to know based on the name and, since they mean =

something=20
 closer to what the function actually does but not quite, they risk misl=

eading=20
 you as to what the function does. At least with iota, you know that you=

're going=20
 to have to look it up.
=20
 There's already precedent for iota as Andrei has stated, and it's been =

in=20
 std.algorithm for a while, so I'm fine with leaving it as is. It's a hi=

ghly=20
 memborable name, and it's nice and short to boot.
=20

	The problem is that =E2=80=9Ciota=E2=80=9D *does* make sense, but it is =
used in a
way quite different from its meaning. So when you see it you do not
look it up, but instead assume that you know what it means and do
not understand how the code you are looking at works.

		Jerome
--=20
mailto:jeberger free.fr
http://jeberger.free.fr
Jabber: jeberger jabber.fr

Jonathan M Davis <jmdavisProg gmx.com> writes:

On Saturday 12 February 2011 07:53:34 J=C3=A9r=C3=B4me M. Berger wrote:
 Jonathan M Davis wrote:
 On Saturday 12 February 2011 02:33:12 Jeff Nowakowski wrote:
 On 02/11/2011 11:14 PM, Jonathan M Davis wrote:
 If anyone tried to use iota to actually mean something as a variable
 or function name, I'd be suggesting that they pick a better nam.

=20
 So you're saying you don't like Andrei's chosen name? ;)

=20
 No. Andrei isn't trying to use the word based on its actual meaning. As
 it stands, the name is essentially nonsensical. That means that it's a
 vey poor name from the standpoint of figuring out what the function does
 based on its name.
=20
 _However_, precisely because it's such a short and nonsensical name, it=


's
 really easy to remember. I'm fine with keeping it as is. If someone
 could come up with a perfect replacement, then that woludn't be too bad,
 but honestly, I think that most of the names suggested actually increase
 the confusion.
=20
 With iota, you don't have a clue what it does based on its name, so you
 look it up. Then you remember it, because it's very memborable. With
 something like walk or interval, the name gives you a better idea of
 what it does, but it's _still_ not good enough for you to know based on
 the name and, since they mean something closer to what the function
 actually does but not quite, they risk misleading you as to what the
 function does. At least with iota, you know that you're going to have to
 look it up.
=20
 There's already precedent for iota as Andrei has stated, and it's been =


in
 std.algorithm for a while, so I'm fine with leaving it as is. It's a
 highly memborable name, and it's nice and short to boot.

=20
 	The problem is that =E2=80=9Ciota=E2=80=9D *does* make sense, but it is =

used in a
 way quite different from its meaning. So when you see it you do not
 look it up, but instead assume that you know what it means and do
 not understand how the code you are looking at works.

And how on earth does iota make sense in this context? I don't see how you =
could=20
possibly look at iota(0, 10) or iota(2, 21, 3); and think that it _anything=
_ to=20
do with its dictionary definiton (per: http://www.merriam-
webster.com/dictionary/iota )

1: the 9th letter of the Greek alphabet =E2=80=94 see alphabet table

2: an infinitesimal amount : jot <did not show an iota of interest>

Honestly, I'd be quicker to think that it was some math term that I wasn't =
aware=20
of than to think that it had _anything_ to do with its English meaning.

=2D Jonathan M Davis

=?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:

Jonathan M Davis wrote:
 And how on earth does iota make sense in this context? I don't see how =

you could=20
 possibly look at iota(0, 10) or iota(2, 21, 3); and think that it _anyt=

hing_ to=20
 do with its dictionary definiton (per: http://www.merriam-
 webster.com/dictionary/iota )
=20
 1: the 9th letter of the Greek alphabet =E2=80=94 see alphabet table
=20
 2: an infinitesimal amount : jot <did not show an iota of interest>
=20
 Honestly, I'd be quicker to think that it was some math term that I was=

n't aware=20
 of than to think that it had _anything_ to do with its English meaning.=

=20

	And what about =E2=80=9Ciota (10)=E2=80=9D which will probably be the mo=
st common
form? Like I already said in another post, people will understand
(and have understood) this as meaning =E2=80=9Ca range with a single
element, that element being 10=E2=80=9D.

		Jerome
--=20
mailto:jeberger free.fr
http://jeberger.free.fr
Jabber: jeberger jabber.fr

spir <denis.spir gmail.com> writes:

On 02/12/2011 02:36 PM, Jonathan M Davis wrote:
 With something like walk
 or interval, the name gives you a better idea of what it does, but it's _still_
 not good enough for you to know based on the name and, since they mean
something
 closer to what the function actually does but not quite, they risk misleading
 you as to what the function does.

This is partially true. But think at this: every name can only be polysemic, by 
the very nature of languages, I mean all languages used by humans. Then, in 
context, especially more formal ones like PLs, they have a chance to take a 
better defined sense.
The whole problem is to try and compose a lexicon, a set of names, that is 
clear, consistent, organised, in such a way that every single name can (at 
least have a chance to) evoke its actual semantics. And not be misleading or 
ambiguous. Which is hard when the language evolves.

Following your statement above, then *all* names in *all* programming languages 
are wrong. None of them perfectly means, as a word, what in means in the 
language; even less for all programmers. The only solution to comply with your 
request is to apply the procedure I posted earlier, namely random generation + 
filter on "bad strikes" (names that by chance still evoke their sense). 'iota' 
is not even even good in this respect since it is not free of any cognitice 
connexion to its actual meaning (--> at least 2 of us thought it means a single 
(minuscule) step).

Conversely, names more or less, or not really, "good enough" in pure 
abstraction, like "interval", can be very good /in context/:

	filter!`a%2==1`(interval(1,10));

Do you have any problem in interpreting this? (Without prior knowledge of D 
arcanes, I certainly have an unsolvable problem in interpreting the part 
between "filter" and the parens; both `...` and '!', in fact.)
Now, replace with iota and imagine what programmers think/guess when reading 
the D version online...
(*)

Denis

(*) Alternatives I would love:

	filter(interval(1,10), {n : n%2==1});
	filter(1..10, {n : n%2==1});

I bet it is close to impossible for a programmer, whatever their background, to 
not understand those versions /at once/ --provided they know the signs '%' and 
'==', and that intervals are supposed to be right-open.
-- 
_________________
vita es estrany
spir.wikidot.com

Jim <bitcirkel yahoo.com> writes:

Andrei Alexandrescu Wrote:

 On 2/11/11 7:07 AM, foobar wrote:
 Andrei Alexandrescu Wrote:

 I don't find the name "iota" stupid.

 Andrei

 Of course _you_ don't. However practically all the users _do_ find it
 poorly named, including other developers in the project.. This is the
 umpteenth time this comes up in the NG and incidentally this is the
 only reason I know what the function does.

 If the users think the name is stupid than it really is. That's how
 usability works and the fact the you think otherwise or that it might
 be more accurate mathematically is really not relevant. If you want
 D/Phobos to be used by other people besides yourself you need to
 cater for their requirements.

 
 Not all users dislike iota, and besides arguments ad populum are 
 fallacious. Iota rocks. But have at it - vote away, and I'll be glad if 
 a better name for iota comes about.
 
 Andrei


list(2, 8)

line(2, 8)

step(2, 8)

sequence(2, 8)

consecution(2, 8)

gradate(2, 8)

gradation(2, 8)

progression(2, 8)

row(2, 8)

foobar <foo bar.com> writes:

Andrei Alexandrescu Wrote:

 On 2/11/11 7:07 AM, foobar wrote:
 Andrei Alexandrescu Wrote:

 I don't find the name "iota" stupid.

 Andrei

 Of course _you_ don't. However practically all the users _do_ find it
 poorly named, including other developers in the project.. This is the
 umpteenth time this comes up in the NG and incidentally this is the
 only reason I know what the function does.

 If the users think the name is stupid than it really is. That's how
 usability works and the fact the you think otherwise or that it might
 be more accurate mathematically is really not relevant. If you want
 D/Phobos to be used by other people besides yourself you need to
 cater for their requirements.

 
 Not all users dislike iota, and besides arguments ad populum are 
 fallacious. Iota rocks. But have at it - vote away, and I'll be glad if 
 a better name for iota comes about.
 
 Andrei

Usability seems to be Achilles' heel of D and is a recurrent theme on the NG.
Usability cannot be mathematically deduced even though you seem to try hard to
do just that. 
This reminds me the story of a Google designer that quit the company, being
frustrated by the engineering mind-set of the company. He gave many amusing
examples of a complete lack of understanding of design principals such as
choosing the shade of blue by doing a "scientific" comparison of a thousand
different shades. 

could we for once put aside otherwise valid implementation concerns such as
efficiency and mathematical correctness and treat usability as valid important
concern? 
Could we for once accept that The users' opinion is not "fallacious" and have a
user oriented design is not a bad thing or are we implementing for the sake of
boosting ones own ego and nothing else? 
 

Lutger Blijdestijn <lutger.blijdestijn gmail.com> writes:

foobar wrote:

 Andrei Alexandrescu Wrote:
 
 On 2/11/11 7:07 AM, foobar wrote:
 Andrei Alexandrescu Wrote:

 I don't find the name "iota" stupid.

 Andrei

 Of course _you_ don't. However practically all the users _do_ find it
 poorly named, including other developers in the project.. This is the
 umpteenth time this comes up in the NG and incidentally this is the
 only reason I know what the function does.

 If the users think the name is stupid than it really is. That's how
 usability works and the fact the you think otherwise or that it might
 be more accurate mathematically is really not relevant. If you want
 D/Phobos to be used by other people besides yourself you need to
 cater for their requirements.

 
 Not all users dislike iota, and besides arguments ad populum are
 fallacious. Iota rocks. But have at it - vote away, and I'll be glad if
 a better name for iota comes about.
 
 Andrei

 
 Usability seems to be Achilles' heel of D and is a recurrent theme on the
 NG. Usability cannot be mathematically deduced even though you seem to try
 hard to do just that. This reminds me the story of a Google designer that
 quit the company, being frustrated by the engineering mind-set of the
 company. He gave many amusing examples of a complete lack of understanding
 of design principals such as choosing the shade of blue by doing a
 "scientific" comparison of a thousand different shades.
 
 could we for once put aside otherwise valid implementation concerns such
 as efficiency and mathematical correctness and treat usability as valid
 important concern? Could we for once accept that The users' opinion is not
 "fallacious" and have a user oriented design is not a bad thing or are we
 implementing for the sake of boosting ones own ego and nothing else?

first rule of usability: don't listen to users

http://www.useit.com/alertbox/20010805.html

foobar <foo bar.com> writes:

Lutger Blijdestijn Wrote:

 
 first rule of usability: don't listen to users
 
 http://www.useit.com/alertbox/20010805.html
 

I fail to see how that page ( which talks about website design ) applies to
what I've said. 
It says that you should look at what people _do_ instead of what they _say_.
How would you apply this to Phobos' naming conventions? 

How about this:
Show a code sample using "iota" to users who never programmed in D and ask them
what that code does. 

Lutger Blijdestijn <lutger.blijdestijn gmail.com> writes:

foobar wrote:

 Lutger Blijdestijn Wrote:
 
 
 first rule of usability: don't listen to users
 
 http://www.useit.com/alertbox/20010805.html
 

 
 I fail to see how that page ( which talks about website design ) applies
 to what I've said. It says that you should look at what people _do_
 instead of what they _say_. How would you apply this to Phobos' naming
 conventions?

Quite literally. The thing is, most average joe users like me don't know 
what's good for them. They don't understand usability directly but rather 
'know it when they see it.'

Of course it is too time-consuming / has too little pay-off to conduct 
experiments for everything.

 How about this:
 Show a code sample using "iota" to users who never programmed in D and ask
 them what that code does.

Exactly, that's a very good idea.

spir <denis.spir gmail.com> writes:

On 02/13/2011 01:17 PM, foobar wrote:
 Lutger Blijdestijn Wrote:

 first rule of usability: don't listen to users

 http://www.useit.com/alertbox/20010805.html

 I fail to see how that page ( which talks about website design ) applies to
what I've said.
 It says that you should look at what people _do_ instead of what they _say_.
How would you apply this to Phobos' naming conventions?

Agreed. I know a bit this design guru's work. The titles of his articles are 
often misleading, even more out of context. What he point to is the common 
practice of design team managers taking decisions based on studies about users 
just giving an advice after a superficial look on the design's appearance; 
often without any trial at using the interface, not to say real usability 
experiments.

To re-center on the case of this thread, I'm 99% sure this guy (the guru) would 
certainly carefully listen to comments from "power-user" who have past 
experience on using other interfaces providing similar functionality, and have 
really tried using the new one for a while.

 How about this:
 Show a code sample using "iota" to users who never programmed in D and ask
them what that code does.

Agreed. On the other hand, I also agree with people stating good design mirrors 
some/one/'s vision...

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

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

On 2/13/11 3:15 AM, foobar wrote:
 Andrei Alexandrescu Wrote:

 On 2/11/11 7:07 AM, foobar wrote:
 Andrei Alexandrescu Wrote:

 I don't find the name "iota" stupid.

 Andrei

 Of course _you_ don't. However practically all the users _do_ find it
 poorly named, including other developers in the project.. This is the
 umpteenth time this comes up in the NG and incidentally this is the
 only reason I know what the function does.

 If the users think the name is stupid than it really is. That's how
 usability works and the fact the you think otherwise or that it might
 be more accurate mathematically is really not relevant. If you want
 D/Phobos to be used by other people besides yourself you need to
 cater for their requirements.

 Not all users dislike iota, and besides arguments ad populum are
 fallacious. Iota rocks. But have at it - vote away, and I'll be glad if
 a better name for iota comes about.

 Andrei

 Usability seems to be Achilles' heel of D and is a recurrent theme on the NG.
Usability cannot be mathematically deduced even though you seem to try hard to
do just that.

I think it would be a bit of an exaggeration to characterize the choice 
of name "iota" as an impediment to usability. I'd agree if it were an 
endemic problem, but generally I think the choice of names in Phobos is 
adequate.

 This reminds me the story of a Google designer that quit the company,
 being frustrated by the engineering mind-set of the company. He gave
 many amusing examples of a complete lack of understanding of design
 principals such as choosing the shade of blue by doing a "scientific"
 comparison of a thousand different shades.

"Principles"!!! "Principles"!!! I hate that typo.

 could we for once put aside otherwise valid implementation concerns
 such as efficiency and mathematical correctness and treat usability
 as valid important concern? Could we for once accept that The users'
 opinion is not "fallacious" and have a user oriented design is not a
 bad thing or are we implementing for the sake of boosting ones own
 ego and nothing else?

I've already mentioned: I'm ready to change this name and others if 
consensus comes about. Generally efficiency and mathematical correctness 
don't clash badly with choice of names, so probably you're referring to 
something beyond that - just let us know.


Andrei

foobar <foo bar.com> writes:

Andrei Alexandrescu Wrote:

 On 2/13/11 3:15 AM, foobar wrote:
 Andrei Alexandrescu Wrote:

 On 2/11/11 7:07 AM, foobar wrote:
 Andrei Alexandrescu Wrote:

 I don't find the name "iota" stupid.

 Andrei

 Of course _you_ don't. However practically all the users _do_ find it
 poorly named, including other developers in the project.. This is the
 umpteenth time this comes up in the NG and incidentally this is the
 only reason I know what the function does.

 If the users think the name is stupid than it really is. That's how
 usability works and the fact the you think otherwise or that it might
 be more accurate mathematically is really not relevant. If you want
 D/Phobos to be used by other people besides yourself you need to
 cater for their requirements.

 Not all users dislike iota, and besides arguments ad populum are
 fallacious. Iota rocks. But have at it - vote away, and I'll be glad if
 a better name for iota comes about.

 Andrei

 Usability seems to be Achilles' heel of D and is a recurrent theme on the NG.
Usability cannot be mathematically deduced even though you seem to try hard to
do just that.

 
 I think it would be a bit of an exaggeration to characterize the choice 
 of name "iota" as an impediment to usability. I'd agree if it were an 
 endemic problem, but generally I think the choice of names in Phobos is 
 adequate.
 

It's not just a one time thing with one function name. There is a reoccurring
pattern with function names and other such aspects and it doesn't need to be
endemic in order to be looked at and improved. 
 
It's not just the naming (which I don't think is adequate), it's other things
too such as the organization & categorization of the code in Phobos, the
web-site (already being worked on), the tool-chain could be improved, etc. 
I'm mostly complaining about the parts where there is little to no
improvements. 

 This reminds me the story of a Google designer that quit the company,
 being frustrated by the engineering mind-set of the company. He gave
 many amusing examples of a complete lack of understanding of design
 principals such as choosing the shade of blue by doing a "scientific"
 comparison of a thousand different shades.

 
 "Principles"!!! "Principles"!!! I hate that typo.

Excuse me but I'm not a native English speaker and the spell check missed that. 

 
 could we for once put aside otherwise valid implementation concerns
 such as efficiency and mathematical correctness and treat usability
 as valid important concern? Could we for once accept that The users'
 opinion is not "fallacious" and have a user oriented design is not a
 bad thing or are we implementing for the sake of boosting ones own
 ego and nothing else?

 
 I've already mentioned: I'm ready to change this name and others if 
 consensus comes about. Generally efficiency and mathematical correctness 
 don't clash badly with choice of names, so probably you're referring to 
 something beyond that - just let us know.
 
 
 Andrei

bearophile <bearophileHUGS lycos.com> writes:

Andrej Mitrovic:

 I'm getting more and more convinced to join the iota camp. The new
 syntax barely saves any characters, and is potentially confusing.


Simen kjaeraas:

 This is also an interesting point. If a..b were to be a separate type,
 opSlice would no longer need to exist, it could be a simple overload
 of opIndex.

See the last part, about __getitem__ and slice() of Python:
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=129228

Bye,
bearophile

Nick_B <nick.NOSPAMbarbalich gmail.com> writes:

Here is a comment by Jeff_S, near the bottom of the comments re 
Microsoft taking over Nokia.

I now worry that the wonderful Qt C++ GUI library, that Nokia now owns 
with it's acquisition of Trolltech a few years ago, will now founder in 
stagnation.

The optimist in me hopes that it will ported to Win Phone 7. But the 
realist in me says "fat chance". With this huge deal with MS, and Qt 
being cross platform, and MS being all about MS platforms and dev tools, 
Qt is now likely toast. Sad.

Good thing it's open source. It will still have life as a separate open 
source entity, but without the paid developers at Nokia working on it, 
it's progress will slow dramatically. There is only so much slack the 
community is capable of taking up.

I'm also scratching my head on this, in terms of what Nokia gets out of 
this. They are essentially trading a larger, more successful, more 
established, platform and ecosystem (Symbian) and large developer mind 
share, for a much smaller, much less successful, much less developer 
mind share platform and ecosystem (Win Phone 7 and Silverlight).

original URL here
see: 
http://www.betanews.com/joewilcox/article/Nokia-swaps-one-burning-platform-for-another-in-Microsofts-silent-takeover-of-the-Finnish-phone-maker/1297438206?awesm=betane.ws_yJ&utm_content=api&utm_medium=betane.ws-twitter&utm_source=twitter.com

cheers
Nick

retard <re tard.com.invalid> writes:

Mon, 14 Feb 2011 13:03:42 +1300, Nick_B wrote:

 I'm also scratching my head on this, in terms of what Nokia gets out of
 this. They are essentially trading a larger, more successful, more
 established, platform and ecosystem (Symbian) and large developer mind
 share, for a much smaller, much less successful, much less developer
 mind share platform and ecosystem (Win Phone 7 and Silverlight).

Money? http://www.istockanalyst.com/article/viewiStockNews/
articleid/4886090

Caligo <iteronvexor gmail.com> writes:

On Sun, Feb 13, 2011 at 6:03 PM, Nick_B <nick.NOSPAMbarbalich gmail.com>wrote:

 Here is a comment by Jeff_S, near the bottom of the comments re Microsoft
 taking over Nokia.

 I now worry that the wonderful Qt C++ GUI library, that Nokia now owns with
 it's acquisition of Trolltech a few years ago, will now founder in
 stagnation.

 The optimist in me hopes that it will ported to Win Phone 7. But the
 realist in me says "fat chance". With this huge deal with MS, and Qt being
 cross platform, and MS being all about MS platforms and dev tools, Qt is now
 likely toast. Sad.

 Good thing it's open source. It will still have life as a separate open
 source entity, but without the paid developers at Nokia working on it, it's
 progress will slow dramatically. There is only so much slack the community
 is capable of taking up.

 I'm also scratching my head on this, in terms of what Nokia gets out of
 this. They are essentially trading a larger, more successful, more
 established, platform and ecosystem (Symbian) and large developer mind
 share, for a much smaller, much less successful, much less developer mind
 share platform and ecosystem (Win Phone 7 and Silverlight).

 original URL here
 see:
 http://www.betanews.com/joewilcox/article/Nokia-swaps-one-burning-platform-for-another-in-Microsofts-silent-takeover-of-the-Finnish-phone-maker/1297438206?awesm=betane.ws_yJ&utm_content=api&utm_medium=betane.ws-twitter&utm_source=twitter.com

 cheers
 Nick

Stop spreading FUD.

Qt is not an open source project.  Qt is Free software (GPL/LGPL) which is
also dual licensed (commercial license) for development of proprietary and
commercial software.  Even if Microsoft was the copyright holder of Qt,
nothing would stop anyone from modifying the source code and continuing its
development.  Besides, Qt is a source of income for Nokia because many large
companies use it for their projects.

"Nick Sabalausky" <a a.a> writes:

"Caligo" <iteronvexor gmail.com> wrote in message 
news:mailman.1613.1297648969.4748.digitalmars-d puremagic.com...
 Qt is not an open source project.  Qt is Free software (GPL/LGPL) which is
 also dual licensed (commercial license) for development of proprietary and
 commercial software.  Even if Microsoft was the copyright holder of Qt,
 nothing would stop anyone from modifying the source code and continuing 
 its
 development.  Besides, Qt is a source of income for Nokia because many 
 large
 companies use it for their projects.

[/me gets up on soapbox]
Distinctions between "open source" and "free software", and the assosiated 
FSF/Stallman vs. OSI geek-off/slapping-fight, make me want to claw my ears 
out and run screaming towards 100% closed/proprietary everything.
[/me steps back down]

Jonathan M Davis <jmdavisProg gmx.com> writes:

On Sunday 13 February 2011 22:51:02 Nick Sabalausky wrote:
 "Caligo" <iteronvexor gmail.com> wrote in message
 news:mailman.1613.1297648969.4748.digitalmars-d puremagic.com...
 
 Qt is not an open source project.  Qt is Free software (GPL/LGPL) which
 is also dual licensed (commercial license) for development of
 proprietary and commercial software.  Even if Microsoft was the
 copyright holder of Qt, nothing would stop anyone from modifying the
 source code and continuing its
 development.  Besides, Qt is a source of income for Nokia because many
 large
 companies use it for their projects.

 
 [/me gets up on soapbox]
 Distinctions between "open source" and "free software", and the assosiated
 FSF/Stallman vs. OSI geek-off/slapping-fight, make me want to claw my ears
 out and run screaming towards 100% closed/proprietary everything.
 [/me steps back down]

LOL. On the whole, software is neither Free Software or Open Source. It may
have 
a license that allows you to follow either of those philosophies, but Free 
Software and Open Source are really ideologies of the the people writing or 
using code, not the code itself. Most people just use the term open source, I 
believe, and most people don't care about the distinction. For some people, it 
seems to be a matter of life and death though. I suppose that you can just use 
the term FOSS if you want to be politically correct.

- Jonathan M Davis