Wrong semantic of newtype

[yuxuanchiadm]

Consider following code:

newtype Bar = Bar { getBar :: String }

foo :: Bar -> ()
foo (Bar _) = ()

main = println (foo undefined)

What is the result of this program? Since newtype is perfect isomorphism. Code above should identical to:

foo :: String -> ()
foo _ = ()

main = println (foo undefined)

Which should display "()" in console. But program instead simply crashed. Because definition of foo generated code final public static short foo(final String/*<Character>*/ arg$1). Which is not lazy. And compiler gererates code foo(PreludeBase.<String/*<Character>*/>undefined().call()). So we got ⊥.

[yuxuanchiadm]

Related to #293.

[Ingo60]

You are right, but there is one reason for doing it this way, even if this might be different in Haskell. And this is that

foo (Bar _) = ()

looks exactly like

foo (Just _) = ()

The behavior of the Frege compiler is so that just by looking at that line you'll know that the argument is strict. You don't have to know that Bar is a newtype constructor and Just is a sum type constructor, and that there are supposed to be subtle semantic differences.

All you need to know is: Ohh, this pattern deconstructs something, hence it will be strict.

[yuxuanchiadm]

I still think pattern match on constructor of newtype designed as strict will not be reasonable. It always will be wired in some case. Consider this:

newtype Bar = Bar { getBar :: String }

foo :: Bar -> ()
foo (Bar _) = ()

main = println (foo (Bar undefined))

Now does it feel the pattern match should always don't fail? The pattern should only strict on constructor right? We don't care about what value it contains. But we still get ⊥ if we deal pattern match as strict.

The best way to think about newtype imo is: It just synonym of the type. We use constructor, pattern match every time when we want to convert between them. The convert should be prefect. So we are not really create new data type or pattern match on data type. We just want to change the name of type.