Also again, taking this way I can not provide several constructors taking inputs of different types, can I ?

You can have multiple constructors, taking different numbers and types of input parameters, yes.

On Mar 10, 2013, at 11:47 AM, Peter Caspers wrote:

Thank you all for your answers, this helps a lot. To clarify my last point ...

...

...

Also again, taking this way I can not provide several constructors taking inputs of different types, can I ? Sorry, didn't get what you mean here.

In C++ it is perfectly normal to have overloaded functions like

f : Int -> Int -> Int f : Int -> Char -> Int

in coexistence, because the compiler can infer (at compile time) what function to call by looking at the arguments types.

In Haskell I think this is not possible simply due to the flexibility given by partial function application, i.e.

f 5

would not be well defined any more, it could be Int -> Int or Char -> Int.

Well, that's what typeclasses are for. class F a where f :: Int -> a -> Int instance F Int where f = ... instance F Char where f = ... ghci> :t f 5 ghci> f 5 :: (F a) => a -> Int

...

In C++ it is perfectly normal to have overloaded functions like

f : Int -> Int -> Int f : Int -> Char -> Int Something that may not be obvious about Haskell is that Haskell does NOT have overloaded functions/operators at all.

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 ? 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"). 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 ? Or would you do it differently from the start ? Thank you Peter

Hi Daniel,

Instead of raising an error it's more secure to return a Maybe value.

date :: Int -> Maybe Date date serialNumber | serialNumber > 0 = Just $ Date serialNumber | otherwise = Nothing

yes, I understand (Maybe seems the equivalent of c++'s boost::optional<T>).

...

-- smart constructor with day month year date2 day month year | month >= 1 && month <=12 = undefined | otherwise = error ("invalid month " ++ show month) To increase type safety it's a good idea to use as much explicit data types instead of Int values as possible:

data Month = January | ...

ok, I will try to change my code in that direction. The idea is clear.

I would use the descriptive names but leave out the 'date', because you could still have:

import qualified Date

Date.fromSerialNumber

also clear, yes. I think I have a better starting point now. Not impossible that I will come back later with further questions :-) Thank you for your help Peter

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.

On Mar 12, 2013, at 12:44 AM, "Richard A. O'Keefe" wrote:

Prelude> :type (+) (+) :: Num a => a -> a -> a

The predefined (+) in Haskell requires its arguments and its result to be precisely the same type.

I think you had better justify the claim that Date+Period -> Date and Date+Period -> Period are possible at the same time by showing us actual code.

Ehm... import Prelude hiding (Num) class SumDP a where (+) :: Date -> Period -> a instance SumDP Date where date + period = instance SumDP Period where date + period =

12.03.2013, 02:53, "Richard A. O'Keefe" :

On 12/03/2013, at 10:00 AM, MigMit wrote:

...

 On Mar 12, 2013, at 12:44 AM, "Richard A. O'Keefe" wrote:

...

 Prelude> :type (+)  (+) :: Num a => a -> a -> a

 The predefined (+) in Haskell requires its arguments and its result  to be precisely the same type.

 I think you had better justify the claim that Date+Period -> Date and  Date+Period -> Period are possible at the same time by showing us  actual code.  Ehm...

 import Prelude hiding (Num)  class SumDP a where (+) :: Date -> Period -> a  instance SumDP Date where date + period =  instance SumDP Period where date + period =

Notice the difference? I said that THE PREDEFINED (+) in Haskell requires its arguments and its result to be precisely the same type.

This example is not the predefined (+); it's another variable entirely that happens to have the same short name and cannot also add integers.

So? You've said:

I think you had better justify the claim that Date+Period -> Date and Date+Period -> Period are possible at the same time by showing us actual code.

You didn't say THIS (+) should be the "predefined" one. And, since you were replying to what Carlos said, and he didn't say it either, my code is still a valid example. Of course, you can refine your request so that it would mention the "predefined" (+), but that would be off-topic here.

On Tue, Mar 12, 2013 at 1:52 PM, Carlos Camarao wrote:

Sorry, I think my sentence: "To define (+) as an overloaded operator in Haskell, you have to define and use a type class." is not quite correct. I meant that to define any operator in Haskell you have to have a type class defined with that operator as member.

What? An operator is just an infix function, taken from the set of symbols. Any function can be an operator (and is, via `func` syntax). No typeclass is required to define a random operator. What did you really mean to say there? -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

Carlos Camarao wrote:

Sorry, I think my sentence: "To define (+) as an overloaded operator in Haskell, you have to define and use a type class." is not quite correct. I meant that to define any operator in Haskell you have to have a type class defined with that operator as member.

No. Operators and type classes are entirely orthogonal in Haskell. For example, the list concatenation operator (++) is not defined in any type class. It could be. Either the `mplus` of MonadPlus or the `mappend` of Monoid would make sense. But it happens not to be.

Yes, but the requirement of using the "predefined" (+) is an extra requirement (I would call (+) in Haskell not a predefined operator, but an operator whose type is defined in a class (Num) which is in the Prelude). A Haskell programmer can still define versions of (+) where the arguments are of two different types and the result is a third (he cannot though use the two type classes, and thus neither instances of these two type classes, in a program).

I wish we could argue over semantics instead of vocabulary. By calling the (+) of Num "predefined" I meant nothing other than "it is _defined_ in the Haskell report before (_pre_) you or I add any code of our own". We agree on the facts. I don't call it an "extra" requirement. The original context was very clearly that in C++ where you have int+int, int+double, double+int, double+double, char*+int, int+char* and so on all predefined, you can *also* add your own date+period *without* hiding the predefined versions. And _that_ is overloading. If the question is whether Haskell can do overloading, _that_ is what has to be achieved: you can add a *new* interface date+period *without* hiding the ones that were already defined before you started coding. The interesting challenge here is that we should have Date + Period -> Date Date - Period -> Date Period + Date -> Date Period - Date -> ILLEGAL Period + Period -> Deriod Period - Period -> Period Date + Date -> ILLEGAL Date - Date -> Date and _also_ (remember we are trying to beat C++ here) Int +/- Int -> Int. I suspect that this can be done using type-level programming (so that Date + Date and Period - Date _begin_ to type check but then violate a type constraint) but that's where my Haskell skills are most risible.

If you add NoImplicitPrelude, I think you should also be able to do: import Prelude hiding (Num) import qualified Prelude (Num) instance Num a => Plus a a where type PlusResult a a = a a + b = a Prelude.+ b On Tue, Mar 12, 2013 at 2:24 PM, MigMit wrote:

On Mar 13, 2013, at 12:54 AM, "Richard A. O'Keefe" wrote:

...

The interesting challenge here is that we should have

Date + Period -> Date Date - Period -> Date Period + Date -> Date Period - Date -> ILLEGAL Period + Period -> Deriod Period - Period -> Period Date + Date -> ILLEGAL Date - Date -> Date

and _also_ (remember we are trying to beat C++ here) Int +/- Int -> Int.

Well, an obvious suggestion would be to use MultiParamTypeClasses and TypeFamilies:

{- LANGUAGE MultiParamTypeClasses, TypeFamilies -} module Date where import Prelude hiding (Num, (+)) data Date = Date data Period = Period class Plus a b where type PlusResult a b (+) :: a -> b -> PlusResult a b instance Plus Date Period where type PlusResult Date Period = Date Date + Period = Date instance Plus Period Date where type PlusResult Period Date = Date Period + Date = Date instance Plus Period Period where type PlusResult Period Period = Period Period + Period = Period

But I suppose you've been thinking about Haskell98. That, I'm afraid, doesn't seem possible. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

On Tue, Mar 12, 2013 at 5:54 PM, Richard A. O'Keefe wrote:

Carlos Camarao wrote:

>> Sorry, I think my sentence: >> "To define (+) as an overloaded operator in Haskell, >> you have to define and use a type class." >>is not quite correct. I meant that to define any operator in Haskell you have to >> have a type class defined with that operator as member.

> No. Operators and type classes are entirely orthogonal in Haskell. > For example, the list concatenation operator (++) is not defined in > any type class. It could be. Either the `mplus` of > MonadPlus or the `mappend` of Monoid would make sense. But it > happens not to be.

I have already corrected myself (repeating, I meant: "To define an _overloaded_ name or operator in Haskell you have to have a type class defined with that name/operator as member").

>> Yes, but the requirement of using the "predefined" (+) is an extra >> requirement (I would call (+) in Haskell not a predefined operator, >> but an operator whose type is defined in a class (Num) which is in the >> Prelude). A Haskell programmer can still define versions of (+) where >> the arguments are of two different types and the result is a third >> (he cannot though use the two type classes, and thus neither instances >> of these two type classes, in a program).

> I wish we could argue over semantics instead of vocabulary. > By calling the (+) of Num "predefined" I meant nothing other than > "it is _defined_ in the Haskell report before (_pre_) you or I add > any code of our own". We agree on the facts.

Ok. But the fact that (+) has type a->a->a is a matter (design decision) related to the definition of class Num in the Haskell Prelude. If (+) had type a->b->c, the fact that

"A Haskell programmer can still define versions of (+) where the arguments are of two different types and the result is a third"

would _not_ depend on hiding and redefining a type class. The programmer could then just define the desired instances.

> I don't call it an "extra" requirement. The original context > was very clearly that in C++ where you have int+int, int+double, > double+int, double+double, char*+int, int+char* and so on all > predefined, you can *also* add your own date+period *without* > hiding the predefined versions. And _that_ is overloading. > If the question is whether Haskell can do overloading, _that_ is > what has to be achieved: you can add a *new* interface > date+period *without* hiding the ones that were already defined > before you started coding.

See above. In this view redefining the type of (+) in class Num

as a->b->c would be sufficient for Haskell to have overloading.

> The interesting challenge here is that we should have > Date + Period -> Date Date - Period -> Date > Period + Date -> Date Period - Date -> ILLEGAL > Period + Period -> Deriod Period - Period -> Period > Date + Date -> ILLEGAL Date - Date -> Date > and _also_ (remember we are trying to beat C++ here) Int +/- Int -> Int. > > I suspect that this can be done using type-level programming (so that > Date + Date and Period - Date _begin_ to type check but then violate > a type constraint) but that's where my Haskell skills are most risible.

Without redefining the type of (+) in the Prelude, the challenge can be met by redefining (+) in another type class (and, yes, if Prelude.(+) is also needed, hiding and importing it qualified). Note though that in this case _polymorphic_ uses of (+), whose instantiation could be for instances of both classes (Prelude.Num and the other one) are not possible. Kind regards, Carlos