News aggregator

Mark Jason Dominus: Two reasons I don't like DateTime's "floating" time zone

Planet Haskell - Wed, 01/08/2014 - 6:58pm

(This is a companion piece to my article about DateTime::Moonpig on the Perl Advent Calendar today. One of the ways DateTime::Moonpig differs from DateTime is by defaulting to UTC time instead of to DateTime's "floating" time zone. This article explains some of the reasons why.)

Perl's DateTime module lets you create time values in a so-called "floating" time zone. What this means really isn't clear. It would be coherent for it to mean a time with an unknown or unspecified time zone, but it isn't treated that way. If it were, you wouldn't be allowed to compare "floating" times with regular times, or convert "floating" times to epoch times. If "floating" meant "unspecified time zone", the computer would have to honestly say that it didn't know what to do in such cases. But it doesn't.

Unfortunately, this confused notion is the default.

Here are two demonstrations of why I don't like "floating" time zones.

1.

The behavior of the set_time_zone method may not be what you were expecting, but it makes sense and it is useful:

my $a = DateTime->new( second => 0, minute => 0, hour => 5, day => 23, month => 12, year => 2013, time_zone => "America/New_York", ); printf "The time in New York is %s.\n", $a->hms; $a->set_time_zone("Asia/Seoul"); printf "The time in Seoul is %s.\n", $a->hms;

Here we have a time value and we change its time zone from New York to Seoul. There are at least two reasonable ways to behave here. This could simply change the time zone, leaving everything else the same, so that the time changes from 05:00 New York time to 05:00 Seoul time. Or changing the time zone could make other changes to the object so that it represents the same absolute time as it did before: If I pick up the phone at 05:00 in New York and call my Mother-in-Law in Seoul, she answers the call at 19:00 in Seoul, so if I change the object's time zone from New York to Seoul, it should change from 05:00 to 19:00.

DateTime chooses the second of these: setting the time zone retains the absolute time stored by the object, so this program prints:

The time in New York is 05:00:00. The time in Seoul is 19:00:00.

Very good. And we can get to Seoul by any route we want:

$a->set_time_zone("Europe/Berlin"); $a->set_time_zone("Chile/EasterIsland"); $a->set_time_zone("Asia/Seoul"); printf "The time in Seoul is still %s.\n", $a->hms;

This prints:

The time in Seoul is still 19:00:00.

We can hop all around the globe, but the object always represents 19:00 in Seoul, and when we get back to Seoul it's still 19:00.

But now let's do the same thing with floating time zones:

my $b = DateTime->new( second => 0, minute => 0, hour => 5, day => 23, month => 12, year => 2013, time_zone => "America/New_York", ); printf "The time in New York is %s.\n", $b->hms; $b->set_time_zone("floating"); $b->set_time_zone("Asia/Seoul"); printf "The time in Seoul is %s.\n", $b->hms;

Here we take a hop through the imaginary "floating" time zone. The output is now:

The time in New York is 05:00:00. The time in Seoul is 05:00:00.

The time has changed! I said there were at least two reasonable ways to behave, and that set_time_zone behaves in the second reasonable way. Which it does, except that conversions to the "floating" time zone behave the first reasonable way. Put together, however, they are unreasonable.

2. use DateTime; sub dec23 { my ($hour, $zone) = @_; return DateTime->new( second => 0, minute => 0, hour => $hour, day => 23, month => 12, year => 2013, time_zone => $zone, ); } my $a = dec23( 8, "Asia/Seoul" ); my $b = dec23( 6, "America/New_York" ); my $c = dec23( 7, "floating" ); printf "A is %s B\n", $a < $b ? "less than" : "not less than"; printf "B is %s C\n", $b < $c ? "less than" : "not less than"; printf "C is %s A\n", $c < $a ? "less than" : "not less than";

With DateTime 1.04, this prints:

A is less than B B is less than C C is less than A

There are non-transitive relations in the world, but comparison of times is not among them. And if your relation is not transitive, you have no business binding it to the < operator.

However...

Rik Signes points out that the manual says:

If you are planning to use any objects with a real time zone, it is strongly recommended that you do not mix these with floating datetimes.

However, while a disclaimer in the manual can document incorrect behavior, it does not annul it. A bug doesn't stop being a bug just because you document it in the manual. I think it would have been possible to implement floating times sanely, but DateTime didn't do that.

[ Addendum: Rik has now brought to my attention that while the main ->new constructor defaults to the "floating" time zone, the ->now method always returns the current time in the UTC zone, which seems to me to be a mockery of the advice not to mix the two. ]

Categories: Offsite Blogs

Dijkstra on Haskell and Java

del.icio.us/haskell - Wed, 01/08/2014 - 5:49pm
Categories: Offsite Blogs

Dijkstra on Haskell and Java

del.icio.us/haskell - Wed, 01/08/2014 - 2:16pm
Categories: Offsite Blogs

ICFP 2014: Call for papers

haskell-cafe - Wed, 01/08/2014 - 3:48am
===================================================================== 19th ACM SIGPLAN International Conference on Functional Programming ICFP 2014 Gothenburg, Sweden, 1-3 September 2014 http://www.icfpconference.org/icfp2014 ===================================================================== Important Dates ~~~~~~~~~~~~~~~ Submissions due: Saturday, 1 March 2014, 23:59 UTC-11 (anywhere in the world) Author response: Wednesday, 23 April, 2014 Friday, 25 April, 2014 Notification: Monday, 5 May, 2014 Final copy due: Wednesday, 11 June, 2014 Scope ~~~~~ ICFP 2014 seeks original papers on the art and science of functional programming. Submissions are invited on all topics from principles to practice, from foundations to features, and from abstraction to application. The scope includes all languages that encourage functional programming, including both purely applicative and imperative languages, as well as languag
Categories: Offsite Discussion

ICFP 2014: Call for papers

General haskell list - Wed, 01/08/2014 - 3:47am
===================================================================== 19th ACM SIGPLAN International Conference on Functional Programming ICFP 2014 Gothenburg, Sweden, 1-3 September 2014 http://www.icfpconference.org/icfp2014 ===================================================================== Important Dates ~~~~~~~~~~~~~~~ Submissions due: Saturday, 1 March 2014, 23:59 UTC-11 (anywhere in the world) Author response: Wednesday, 23 April, 2014 Friday, 25 April, 2014 Notification: Monday, 5 May, 2014 Final copy due: Wednesday, 11 June, 2014 Scope ~~~~~ ICFP 2014 seeks original papers on the art and science of functional programming. Submissions are invited on all topics from principles to practice, from foundations to features, and from abstraction to application. The scope includes all languages that encourage functional programming, including both purely applicative and imperative languages, as well as languag
Categories: Incoming News

Right approach to profiling and optimizing aconcurrent data structure?

haskell-cafe - Wed, 01/08/2014 - 3:19am
Happy New Year, all, I started what I thought would be a pretty straightforward project to implement a concurrent queue (with semantics like Chan) which I hoped would be faster, but the process of trying to measure and test performance has been super frustrating. I started with a really big criterion benchmark suite that ran through a bunch of Chan-like implementations as well as comparing different var primitives; I was compiling that with `-O2 -threaded` and running with +RTS -N (as that seemed realistic, and results were very consistent). Short version: at some point I realized I had (in my cabal config) enabled executable-profiling, which when disabled completely changed all timing and actually *hurt* performance. Then after a lot more head-banging I realized that +RTS -N seems to run on only one core when compiled with -prof (I didn't see that documented anywhere) although I could *force* the -prof version to use more with -N2, and so apparently for my tests[1], running on a single core just *happen
Categories: Offsite Discussion

How do you reference the name of a class from inside a default implementation of its functions?

Haskell on Reddit - Wed, 01/08/2014 - 12:46am

Relative newbie to Haskell here. I'd like to define a class with a default implementation of one of its functions, and that implementation defines other functions in a let statement. I'd like to specify the type of one of these subfunctions, which involves the type specified by the class. Here's a toy example:

class NormalizedList t where toList :: (Fractional n) => t -> [n] fromList :: (Fractional n) => [n] -> t normalize :: t -> t normalize contents = let total = sum $ toList contents divideBy :: (Fractional n) => t -> n -> t -- This is the line with the problem. divideBy contents divisor = fromList $ map (/ divisor) (toList contents) in divideBy contents total

When I try compiling this, Haskell complains that it "Could not deduce (NormalizedList t1) arising from a use of 'fromList' from the context (NormalizedList t) bound by the class declaration for 'NormalizedList'". Any suggestions on how I can change this so it realizes that the t mentioned in divideBy's type is the same as the t being defined in the NormalizedList class?

If I comment out the type signature of divideBy, everything works fine. In my actual code, though, I have a more complicated function and it's having trouble figuring out the proper type (or perhaps I have a mistake somewhere), which is why I wanted to specify the type in the first place.

Thanks in advance for the help.

submitted by penguinland
[link] [12 comments]
Categories: Incoming News

Drop or update the upper bounds of numerals andnumerals-base

haskell-cafe - Tue, 01/07/2014 - 11:38pm
I’ve built both packages locally, and they seem to work fine with GHC 7.6.3. However, I can’t install them from Hackage due to the required dependencies. Could anyone drop or update the upper bounds? Alternatively, I could try to do so myself if someone provides the required permissions. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe< at >haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Categories: Offsite Discussion

happstack-fastcgi maintenance

haskell-cafe - Tue, 01/07/2014 - 10:54pm
I've patched happstack-fastcgi to work with the latest versions of ghc and happstack. The maintainers have expressed that they consider it unmaintained. I would like to gauge the interest in the library and perhaps maintain it. Let me know if this is of interest to anyone. Have you used it in the past? What features would you need added? Any changes? -Tom
Categories: Offsite Discussion

Haskell :: Reddit

del.icio.us/haskell - Tue, 01/07/2014 - 10:51pm
Categories: Offsite Blogs

Slow mvar when compiled with threaded

haskell-cafe - Tue, 01/07/2014 - 8:55pm
I have test network client, something like apache bench tool. It uses mvars to synchronize and everything is ok when compiled without -threaded. real 0m2.995s user 0m0.601s sys 0m2.391s With -threaded compile option result is following: real 0m18.196s user 0m2.054s sys 0m3.313s Seems that program is sleeping most of the time for some reason. I can't explain behavior as it seems that program is ok. It starts `concurrency` threads which wait on mvar to process next task. Program follows: {-# Language OverloadedStrings #-} import System.CPUTime import System.IO --import System.IO.Error import Network.Socket hiding(recv) import Network.Socket.ByteString import System.Environment import Control.Concurrent import Control.Exception main = do n <- getArgs let (host,port,conc,reqs) = parse n putStrLn $ "Connecting to " ++ host ++ " " ++ port s <- getAddrInfo Nothing (Just host) (Just port) let servAddr = head s begin <- getCPUTime process servAddr conc reqs
Categories: Offsite Discussion

modular type classes paper

del.icio.us/haskell - Tue, 01/07/2014 - 8:15pm
Categories: Offsite Blogs

Christopher Done: Dijkstra on Haskell and Java

Planet Haskell - Tue, 01/07/2014 - 6:00pm

In 2001, Edsger W. Dijkstra wrote a letter to the Budget Council of The University of Texas. A PDF is available here, I’ve typed it up so that everyone can read it. Sadly, the curriculum was changed to Java. Relatedly, the algorithmic language Scheme was replaced by Python in MIT’s The Structure and Interpretation of Computer Programs version 6.01.

To the members of the Budget Council

I write to you because of a rumor of efforts to replace the introductory programming course of our undergraduate curriculum the functional programming language Haskell by the imperative language Java, and because I think that in this case the Budget Council has to take responsibility lest the decision be taken at the wrong level.

You see, it is no minor matter. Colleagues from outside the state (still!) often wonder how I can survive in a place like Austin, Texas, automatically assuming that Texas’s solid conservatism guarantees equally solid mediocrity. My usual answer is something like “Don’t worry. The CS Department is quite an enlightened place, for instance for introductory programming we introduce our freshmen to Haskell”; they react first almost with disbelief, and then with envy —usually it turns out that their undergraduate curriculum has not recovered from the transition from Pascal to something like C++ or Java.

A very practical reason for preferring functional programming in a freshman course is that most students already have a certain familiarity with imperative programming. Facing them with the novelty of functional programming immediately drives home the message that there is more to programming than they thought. And quickly they will observe that functional programming elegantly admits solutions that are very hard (or impossible) to formulate with the programming vehicle of their high school days.

A fundamental reason for the preference is that functional programs are much more readily appreciated as mathematical objects than imperative ones, so that you can teach what rigorous reasoning about programs amounts to. The additional advantage of functional programming with “lazy evaluation” is that it provides an environment that discourages operational reasoning12.

Finally, in the specific comparison of Haskell versus Java, Haskell, though not perfect, is of a quality that is several orders of magnitude higher than Java, which is a mess (and needed an extensive advertizing campaign and aggressive salesmanship for its commercial acceptance). It is bad enough that, on the whole, industry accepts designs of well-identified lousiness as “de facto” standards. Personally I think that the University should keep the healthier alternatives alive.

It is not only the violin that shapes the violinist, we are all shaped by the tools we train ourselves to use, and in this respect programming languages have a devious influence: they shape our thinking habits. This circumstance makes the choice of first programming language so important. One would like to use the introductory course as a means of creating a culture that can serve as a basis for computing science curriculum, rather than be forced to start with a lot of unlearning (if that is possible at all: what has become our past, forever remains so). The choice implies a grave responsibility towards our undergraduate students, and that is why it can not be left to a random chairman of something but has to be done by the Budget Council. This is not something that can be left to the civil servants or the politicians; here statesmen are needed.

Austin, 12 April 2001

Edsger W. Dijkstra

  1. On the cruelty of really teaching computing science

  2. Real mathematicians don’t prove

Categories: Offsite Blogs