[Haskell-cafe] New type of expressions containing (error ...) includes noisy implicit parameter

[Nicola Gigante]

> Il giorno 13 feb 2016, alle ore 10:15, Christopher Allen <cma at bitemyapp.com> ha scritto:
> 
> >subtle difference means that you do need to know about this due to how stacks work in GHC. If you use error and then don't also add that constraint yourself to your function, youll only see part of the stack.
> 
> It is unfortunate that the design forces this implementation detail on users trying to apply a plain old function.
> 
> 
> I updated my GHC 8.0.1 candidate, got this:
> 
> $ ghci
> GHCi, version 8.0.0.20160204: http://www.haskell.org/ghc/ <http://www.haskell.org/ghc/>  :? for help
> Loaded GHCi configuration from /home/callen/.ghci
> Prelude> let myList = [1..5 :: Integer]
> Prelude> let myList' = myList ++ undefined
> Prelude> :t myList'
> myList' :: (?callStack::GHC.Stack.Types.CallStack) => [Integer]
> 
> > changed to use constraint kinds and type alias the implicit parameter behind a nicer API.
> 
> Even if this has happened, we're still talking about the fourth chapter which is prior to types, typeclasses, constraints - everything. None of this means anything to a beginner being shown how to use undefined. The book is trying to make sure _anyone_ can learn Haskell, it's not an advanced DSLs book that introduces DataKinds.
> 
> The implementation is leaking all the way to the fourth chapter of a book for complete beginners. Users will not be sympathetic when the implementation elides information because the user failed to speak to the nasal demons in the correct accent.


Hi Christopher, I’m following your painful experience preparing the book for GHC 8.0,
and I sympathize with you.

Just a question: how do you manage the type of simple
arithmetic expressions like 1 + 1? I mean, the type contains a constraint there.

Prelude> :t 1 + 1
1 + 1 :: Num a => a

I suppose that explaining “Num a =>” by saying “it says that the type must be a number”
is easier because of assonance with the word, but is that really a difference?

Note that this situation is much different from the issue about the type of ($):
- Teaching ‘undefined’ to beginners is not essential. It’s use is waaay less common that ($),
  and it should be especially for beginners. Partial functions should be discouraged
  from the start, and maybe a slightly more difficult type can be the right way to make people
  learn to not use it. It’s use comes handy when explaining laziness, maybe. But you
  could obtain the same effect with a never-ending function, which is also theoretically
  more affine to the meaning of “bottom”.
- The constraint explicitly mentions “CallStack” twice. Exactly like “Num”, I think it’s easy to handwave:
  “The 'blahblah =>' part says that the function needs to know the ‘call stack’, which is what
  you see printed when ‘undefined’ gets evaluated and the program exists”. 

So while I agree with you that this type is more difficult to explain, I think it’s much less
of a problem than the new type of ($).

If you don’t agree with any of these points please let me know.

Regards,
Nicola





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20160213/b9c79460/attachment.html>