Stupid little iota of an idea

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Thu Feb 10 14:05:50 PST 2011


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 at 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 at digitalmars.com>
> References: <cd30iv$17m8$1 at digitaldaemon.com>
> <cd3qim$2iov$1 at digitaldaemon.com> <cd481o$adi$4 at digitaldaemon.com>
> <cd4dqj$m1f$1 at digitaldaemon.com> <cd4gnr$rp0$1 at 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 at 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 at stlsoft.dot.dot.dot.dot.org> wrote:
>> "Sean Kelly" <sean at f4.ca> wrote in message
>> news:cd4dqj$m1f$1 at digitaldaemon.com...
>>> In article <cd481o$adi$4 at 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);
>
> I like #2, it allows this...
>
> if (findXyz("regan",value)) {
> }
>
> #1 would be
>
> 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.
>
> My vote is for #2 above.
>
>> 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


More information about the Digitalmars-d mailing list