On Thursday, March 08, 2012 04:26:11 Nick Sabalausky wrote:
> Aside from the problems of excess paren nesting, I tend to think this is backwards:
> 
> foo(bar(baz(x+2)))

Yes, but that's how functions normally work, so flipping it around _is_ backwards from the normal, even if some people find it easier to understand. And I've written enough in functional languages that flipping it around just seems _really_ backwards to me. At this point, I always have a harder time reading code when someone insists on chaining UFCS calls rather than using normal function calls. But obviously YMMV.

- Jonathan M Davis

On Thu, 08 Mar 2012 05:38:08 +1100, Nick Sabalausky <a@a.a> wrote:


> British English may be the more "official" English, with American English as a mere variation ...


In one sense, American English is often a sort of abbreviated version in which seemingly superfluous letters are omitted. But in other cases, it more accurately reflects pronunciation (colorize verses colourise).


> Speaking of...do the British actually pronounce colour with a "u" sound? If
> not, I'd argue "color" really is a better spelling ;) (Not as good as
> "kulr", but whatever)

I'm not sure about British pronunciation (I'm Australian) but 'color' is said as "kull-ore' and 'colour' is said like 'kull-er' or even 'kull-ah'.

But my point, a part from being a bit whimsical, was that we can even have disagreements over fully spelt (spelled?) words let alone abbreviations (ironically that is word that *needs* shortening) so I think the criteria for publicly exposed function names should hinge on the consistency of naming conventions rather than focus on abbrv. vs. FullySpelledOutWords.

-- 
Derek Parnell
Melbourne, Australia

On 03/08/2012 03:14 AM, Ary Manzana wrote:
> Here's something I wrote today:
>
> parent_ids = results.map{|x|
> x['_source']['parent_ids']}.flatten.uniq.compact
> Hash[Site.find(parent_ids).map{|x| [x.id, x]}]
>
> Or I could have written:
>
> Hash[
> Site.find(
> results.map{|x| x['_source']['parent_ids']}.flatten.uniq.compact
> ).map{|x| [x.id, x]}
> ]
>
> No abbreviation at all,

uniq.

On 03/08/2012 03:20 AM, Kapps wrote:
> On Wednesday, 7 March 2012 at 19:12:25 UTC, H. S. Teoh wrote:
>> Supporting stuff like 5.hours will introduce additional complications to
>> D's lexical structure, though. The lexer will have to understand it as
>> (int:5)(.)(ident:hours) rather than (float:5.)(ident:hours). And then if
>> you actually *wanted* a float, you'd have another ambiguity: 5..hours
>> could mean (float:5.)(.)(ident:hours) or (int:5)(..)(hours). And
>> 5.0.hours just looks... weird.
>>
>>
>> T
>
> Actually, Kenji's pull request for UFCS already takes care of this.
> Things like 5. aren't allowed, nor is 5.f; a number has to follow the
> decimal. So 5.f would invoke UFCS function f with the integer 5. I
> believe this change is already merged, though the rest of the UFCS pull
> request isn't unfortunately.

5. is still allowed.

On Thu, 08 Mar 2012 10:21:00 -0000, Derek <ddparnell@bigpond.com> wrote:
> On Thu, 08 Mar 2012 05:38:08 +1100, Nick Sabalausky <a@a.a> wrote:
>
>
>> British English may be the more "official" English, with American English as a mere variation ...
>
>
> In one sense, American English is often a sort of abbreviated version in which seemingly superfluous letters are omitted. But in other cases, it more accurately reflects pronunciation (colorize verses colourise).

In Britain (where I live) there are people to pronounce the 'u' in colour, and colourise.  The difference is subtle, and I've found many people simply cannot hear it.  It's the reason many people (and the brash American tourist stereotype springs to mind - but there are people the world over) have trouble learning and speaking a foreign language, they cannot hear where they're going wrong (or they don't care - which is a different issue).  I think my own ear is able to hear some, perhaps a good number of the subtleties, for example it was good enough that a local Colombian thought I was myself Colombian after having spoken a few short (uncomplicated, as my Spanish is basic at best) sentences with them.

>> Speaking of...do the British actually pronounce colour with a "u" sound? If
>> not, I'd argue "color" really is a better spelling ;) (Not as good as
>> "kulr", but whatever)
>
> I'm not sure about British pronunciation (I'm Australian) but 'color' is said as "kull-ore' and 'colour' is said like 'kull-er' or even 'kull-ah'.

This is why Australians and New Zealanders (myself) should not be asked how to pronounce words, our vowels are all either 'wrong' or missing completely. :p

Back to the main topic, being from NZ, where British English is the standard, I prefer it to American.  But, I can easily adapt to whichever is used in a body of code.

Regan

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

On Wed, 07 Mar 2012 21:14:34 -0500, Ary Manzana <ary@esperanto.org.ar> wrote:

> The problem is not mistaking it with something else. The problem is when you want to write it. In Ruby my mind works like this:
>
> Mind: "How would I get a span for 5 seconds?"
> Mind: "Let's try 5.seconds"
> Mind: "Wow, it works!"
>
> I'm trying to remember cases when I just wrote what my mind thought it was correct and I was *so* surprised it worked out of the box in Ruby. Like writing array.last, and get it to work, instead of array[array.length - 1]. But in D, from the docs (http://dlang.org/arrays.html )
>
> bar[$-1] // retrieves last element of the array
>
> I read: bar dollar minus one wait what??

array.back;

http://dlang.org/phobos/std_array.html#back

This is the issue with "intuition".  It's easy to say, "hey I guessed right in Ruby!  Ruby must be more intuitive!".  But if you were someone who knew the range interfaces, wouldn't you try array.back in Ruby and say "well, obviously D is more intuitive, it knew what I wanted without even looking up the docs!"

You are never going to come up with something that's *perfectly* intuitive for everyone in every situation.

> Now, in D I try:
>
> 5.seconds
>
> and it doesn't work. I have to write this very unintuitive:
>
> dur!"minutes"(5)
>
> Was it really necessary to implement it that way?

No, nothing is ever necessary to implement a certain way.  But there are practical concerns.  For example, assuming UFCS worked in D, you *could* possibly do 5.seconds.  However, this means you need a module-level function:

Duration seconds(long n) {...}

But the way D's overload resolution works, this precludes having 5.seconds work, and also having a member named 'seconds' in your class/struct.

The nice thing about dur!"seconds" is that only one module-level symbol is introduced (dur), and it's unlikely to conflict with local symbols

It may not be as intuitive, but it's certainly readable, and not too verbose to type.

-Steve

On 08/03/2012 02:56, Jonathan M Davis wrote:
> On Thursday, March 08, 2012 01:22:42 Stewart Gordon wrote:
>> On 07/03/2012 08:10, Jacob Carlborg wrote:
>> <snip>
>>
>>> Yeah, Clock.now() would be good and Data.today() as well.
>>
>> My utility library has, for consistency, DateValue.now, TimeValue.now and
>> DateTime.now.
>
> I specically avoided giving a way to get the time with any type other than
> SysTime (and TickDuration for using a monotonic clock), because I believe that
> it leads to incorrect behavior. Any time that you're dealing with the system
> clock, you should be dealing with SysTime. Date, TimeOfDay, and DateTime are
> for when you need the date and/or time but don't care about what absolute time
> it's associated with in the real world.  Treating DateTime as corresponding to
> a specific point in time is just going to cause problems, because it has no
> time zone.
<snip>

TimeValue and DateTime in my library always store the time in UTC.  It uses a global variable for time zone.  But a LocalTime could be added to the mix.  This would be used to hold a time that, when combined with a date, will become a DateTime set according to the correct time zone.

Interestingly, SQL has

DATE - just a date, simple as that
TIME - a time of day in unspecified time zone
TIMETZ - a time of day with time zone specified
TIMESTAMP - a date/time combination in unspecified time zone
TIMESTAMPTZ - an absolute instant in time, which can be constructed and examined according to the system time zone

Notice how different TIMETZ and TIMESTAMPTZ are, even though "TZ" abbreviates " WITH TIME ZONE" in both cases.  Moreover, system time zones (in at least some SQL implementations) include DST rules, whereas the zone stored in a TIMETZ is just a UTC offset.

In my scheme:
- DateValue corresponds to DATE
- TimeValue corresponds to a TIMETZ with the zone set as UTC
- DateTime corresponds to TIMESTAMPTZ
- LocalTime, if it were added, would correspond to TIME

I'd also like to add DST handling to my library, but it'll take thinking about.  I'm not sure what OS APIs have in the way of retrieving the DST rules for the locale.  Though I have just discovered GetDynamicTimeZoneInformation in the Windows API - I'll investigate it later.

Stewart.

On 08/03/2012 11:04, Regan Heath wrote:
> On Thu, 08 Mar 2012 10:21:00 -0000, Derek <ddparnell@bigpond.com> wrote:
>> On Thu, 08 Mar 2012 05:38:08 +1100, Nick Sabalausky <a@a.a> wrote:
>>
>>> British English may be the more "official" English, with American English as a mere
>>> variation ...
>>
>> In one sense, American English is often a sort of abbreviated version in which seemingly
>> superfluous letters are omitted. But in other cases, it more accurately reflects
>> pronunciation (colorize verses colourise).

Indeed.  Sometimes the British spelling is more logical (judgement versus judgment). Sometimes the American spelling is more logical (skeptical versus sceptical).

> In Britain (where I live) there are people to pronounce the 'u' in colour, and colourise.
> The difference is subtle, and I've found many people simply cannot hear it.
<snip>

I'm finding it hard to figure how someone would pronounce the "o" and "u" in "colour" separately.

But to me, it's just the same phoneme as found in most -er and -or words.

Stewart.

I feel compelled to point out that there is no such thing as "British English". There is English, the written language with all its archaic spellings and there are many spoken dialects, the most formal of which is RP (Received Pronunciation) sometimes called The Queen's English (even though she is German).

If we went to the effort of re-spelling words to match how they were spoken, then we would just end up with multiple accepted spellings (and some new letters), or a nation of 1920s radio newscasters, neither of which appeals to me. As it is, the archaic spellings help to make words more visually distinct, after all, we have some words that are spoken the same but spelled differently (and vice versa >< ).

As for identifiers and abbreviations, as long as they are sufficiently visually distinct, I'd be happy. I tolerate USian spellings as much as non-English speaking programmers do, because I see it as an accepted "Programmer's English".

Secondly, D has its "the obvious solution is the right solution" philosophy. so the "right" identifiers should also be the obvious ones, but they should also be short especially when used frequently. Longer identifiers should be used sparingly, but are useful to convey subtleties such as different side effects and of course, to make non-safe code stand out.

A...

On 9 March 2012 01:23, Stewart Gordon <smjg_1998@yahoo.com> wrote:
> On 08/03/2012 11:04, Regan Heath wrote:
>>
>> On Thu, 08 Mar 2012 10:21:00 -0000, Derek <ddparnell@bigpond.com> wrote:
>>>
>>> On Thu, 08 Mar 2012 05:38:08 +1100, Nick Sabalausky <a@a.a> wrote:
>>>
>>>> British English may be the more "official" English, with American
>>>> English as a mere
>>>> variation ...
>>>
>>>
>>> In one sense, American English is often a sort of abbreviated version in
>>> which seemingly
>>> superfluous letters are omitted. But in other cases, it more accurately
>>> reflects
>>> pronunciation (colorize verses colourise).
>
>
> Indeed.  Sometimes the British spelling is more logical (judgement versus
> judgment). Sometimes the American spelling is more logical (skeptical versus
> sceptical).
>
>> In Britain (where I live) there are people to pronounce the 'u' in colour,
>> and colourise.
>> The difference is subtle, and I've found many people simply cannot hear
>> it.
>
> <snip>
>
> I'm finding it hard to figure how someone would pronounce the "o" and "u" in "colour" separately.
>
> But to me, it's just the same phoneme as found in most -er and -or words.
>
> Stewart.

Being British means that I do notice the differences in pronunciation, I've pretty much done the opposite to Reagan, gone from England to NZ. I tend to get frustrated when I can't even correct pronunciation because nobody can hear the difference!

--
James Miller