On 11/03/2013, at 12:10 AM, Peter Caspers wrote:
thanks, this was the core of my question. So by example, if I define a Date type as
data Date = Date Int deriving Show
representing a date by its serial number and want two constructors (conditions are only examples here)
-- smart constructor with serialNumber date serialNumber | serialNumber > 0 = Date serialNumber | otherwise = error ("invalid serialNumber " ++ show serialNumber)
-- smart constructor with day month year date2 day month year | month >= 1 && month <=12 = undefined | otherwise = error ("invalid month " ++ show month)
there is no way of naming both functions date (instead of date2 above, which compiles), right ?
Right.
I still think the basic reason is that
date 5
would then either refer to the first constructor (i.e. representing a date with serial number 5) or a partial application of the second constructor (i.e. representing a function taking month and year and returning the date "5th month, year").
I am having real trouble understanding why you think this. Yes, for an *untyped* language, "date 27" would not know whether to return a date or a closure. But Haskell is *not* an untyped language. The one-identifier-one-visible-interface rule is about making a practical type inference algorithm. I'm also having some trouble understanding why negative serial numbers would be illegal. Dates are a Z-torsor; to convert integers to dates you have to choose an arbitrary origin. My Dershowitz-and-Reingold-inspired Smalltalk calendar library lets you use Julian day number (shifted by 0.5), modified Julian day number, rata die, and ahargana. I've been thinking of allowing a fifth origin: COBOL's 0=31-Dec-1600. "serialNumber" is a bad name because the origin is arbitrary and the name does not reveal what the origin is. You can easily write date :: Either Int (Int Int Int) -> Date date (Left days_since_epoch) = Date days_since_epoch date (Right (year,month,day)) | 1 <= month && month <= 12 && 1 <= day && day <= days_in_month year month = … | otherwise = error ("bad date") Or even set up your own interface type: import System.Time -- to get Month; pity Data.Time doesn't offer that. data Date_Presentation = Julian_Day_Number Int | Modified_Julian_Day_Number Int | Rata_Die Int | Ahargana Int | Days_Since_COBOL_Epoch Int | Gregorian Int Month Int | Julian Int Month Int | Revised_Julian Int Month Int -- more accurate than Gregorian date :: Date_Presentation -> Date date (Julian_Day_Number j) = … … date (Revised_Julian y m d) = … You will notice that this list offers 5 date presentations that use a single number and three that use two numbers and a month name. Overloading is no help with that!
If this is the case, what would be the natural Haskell way of organizing the smart constructors ? Just number them as above ? Or naming them dateFromSerialNumber, dateFromDayMonthYear ?
As noted above, there is NO unique "serial number" for a date and NO unique day/month/year representation either. Smalltalk-80 introduced baStudlyCaps namesThatIsNamesWithInternalCapitals because it was implemented on a machine that used the ASCII 63 left arrow and up arrow instead of the ASCII 67 underscore and caret. So it used the codepoint we associate with underscore for the assignment symbol. In C and C++ and SML and Haskell, we are allowed to use underscores. ThereisnoneedtorunyourwordstogetherOrUseInternalCaps. Nobody_will_shoot_you_for_writing_readably. You should probably take advantage of the module name and call your functions Date.from_julian_day_number :: Int -> Date Date.from_gregorian :: Int -> Month -> Int -> Date
Or would you do it differently from the start ?
One question is support for different calendars. I would probably have a My_Date module that just offers julian day number, modified julian day number, ahagarna, rata die, and maybe a couple of other epochs. I would create nested modules My_Date.Gregorian, My_Date.Julian, My_Date.Revised_Julian, My_Date.Mayan, and so on, so that a new calendar could be supported by just plugging in a new module, not by changing anything. For something without so many alternatives, I might make a different choice.