<div dir="ltr">There's another problem I discovered with HasCallStack. The implicit parameter constraint breaks sharing behavior for examples that use bottom.<div><br></div><div>Observe:</div><div><br></div><div><div>$ ghci</div><div>GHCi, version 8.0.0.20160204: <a href="http://www.haskell.org/ghc/">http://www.haskell.org/ghc/</a> :? for help</div><div>Loaded GHCi configuration from /home/callen/.ghci</div><div>Prelude> let myList = [1, 2, id 1] :: [Integer]</div><div>Prelude> let myList' = myList ++ undefined </div><div>Prelude> :sprint myList'</div><div>myList' = _</div><div>Prelude> head myList'</div><div>1</div><div>Prelude> :sprint myList'</div><div>myList' = _</div><div>Prelude> :t myList'</div><div>myList' :: (?callStack::GHC.Stack.Types.CallStack) => [Integer]</div><div>Prelude> take 2 myList'</div><div>[1,2]</div><div>Prelude> :sprint myList'</div><div>myList' = _</div></div><div><br></div><div><br></div><div><div>$ stack ghci</div><div>Run from outside a project, using implicit global project config</div><div>Using resolver: lts-5.1 from implicit global project's config file: /home/callen/.stack/global-project/stack.yaml</div><div>Error parsing targets: The specified targets matched no packages.</div><div>Perhaps you need to run 'stack init'?</div><div>Warning: build failed, but optimistically launching GHCi anyway</div><div>Configuring GHCi with the following packages: </div><div>GHCi, version 7.10.3: <a href="http://www.haskell.org/ghc/">http://www.haskell.org/ghc/</a> :? for help</div><div>Ok, modules loaded: none.</div><div>Prelude> let myList = [1, 2, id 1] :: [Integer]</div><div>Prelude> let myList' = myList ++ undefined </div><div>Prelude> :sprint myList'</div><div>myList' = _</div><div>Prelude> head myList'</div><div>1</div><div>Prelude> :sprint myList'</div><div>myList' = 1 : _</div></div><div><div>Prelude> take 2 myList'</div><div>[1,2]</div><div>Prelude> :sprint myList'</div><div>myList' = 1 : 2 : _</div></div><div><br></div><div><br></div><div>Now I have to re-examine everywhere we've used bottoms and :sprint together in the book, which includes the chapters on lists, folds, and non-strictness. And it isn't just about our book, what about all the other learning resources and tutorials? :sprint was hard enough for new people to understand to begin with.</div><div><br></div><div>It is very disheartening that people do not take this more seriously.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Feb 13, 2016 at 3:33 PM, Christopher Allen <span dir="ltr"><<a href="mailto:cma@bitemyapp.com" target="_blank">cma@bitemyapp.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Holes and bottoms are wildly different. Bottoms are considerably more useful which I think you'd find if you ran down a list of examples and tried both in each circumstance. This would force even more rewriting than present circumstances.<span class=""><div><br></div><div>><span style="font-size:12.8px">'undefined' is nasty and has to be used with care</span></div><div><span style="font-size:12.8px"><br></span></div></span><div><span style="font-size:12.8px">Ya, we tell them that. We also tell them that programs intended to be executed outside of a learning/development environment should be total (we explain totality and partiality).</span></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Feb 13, 2016 at 3:08 PM, Matthew Pickering <span dir="ltr"><<a href="mailto:matthewtpickering@gmail.com" target="_blank">matthewtpickering@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Maybe it would be better to introduce _ rather than using undefined<br>
for holes in programs. This sidesteps this issue, provides useful<br>
information to guide the implementation and causes an error when code<br>
is compiled so programs aren't unexpectedly partial.<br>
<br>
It is perhaps not idiomatic to use undefined, even in development<br>
these days. It is much easier (imo) to use holes and<br>
-fdefer-type-errors.<br>
<br>
'undefined' is nasty and has to be used with care; CallStacks exist as<br>
a bit of a safety net. I've not read your book but I'm not convinced<br>
it should be emphasised so much in the first chapters of an elementary<br>
Haskell textbook.<br>
<div><div><br>
On Sat, Feb 13, 2016 at 8:52 PM, Christopher Allen <<a href="mailto:cma@bitemyapp.com" target="_blank">cma@bitemyapp.com</a>> wrote:<br>
> Replying to a few here.<br>
><br>
> Gigante:<br>
><br>
>>Just a question: how do you manage the type of simple arithmetic<br>
>> expressions like 1 + 1? I mean, the type contains a constraint there.<br>
>> Prelude> :t 1 + 1<br>
>> 1 + 1 :: Num a => a<br>
><br>
> Earlier versions of the book intentionally juked this or concreted the type<br>
> of numbers to Integer, but HaskellForMac defenestrated that with the<br>
> always-on type showing so now we've had an explanation along the lines you<br>
> suggest for a few months now. We know how to adapt - we've tested the book<br>
> extensively. What we need is the implementation not to expose irrelevant<br>
> magic/noise in ways that could leak into the first chapter with Haskell code<br>
> in it.<br>
><br>
><br>
> Seidel:<br>
><br>
>>If your readers are using :t they must already know about simple types<br>
> like Integer, [], and, ->, so the new things are HasCallStack and =>.<br>
><br>
> You'd bloody think as we're careful when we introduce :t, but we get tickets<br>
> from people using HaskellForMac[1] that get confused because they are shown<br>
> the types of expressions too early. Now we're careful in how we introduce<br>
> _any_ expressions.<br>
><br>
> Fisking your attempt:<br>
><br>
>> => is just like -> except<br>
><br>
> They don't know what either of those things are or what they mean in the<br>
> second chapter because this is the _first_ chapter with any Haskell code.<br>
> They're just beginning to see how Haskell code might be kinda like the<br>
> lambdas in the lambda calculus chapter.<br>
><br>
>> the compiler fills in the argument by<br>
><br>
> We do explain what a compiler and interpreter are, but they won't know what<br>
> it means for it to fill in an argument. They don't know why it needs to fill<br>
> in an argument. Where did the argument come from?<br>
><br>
>> HasCallStack tells the compiler<br>
><br>
> How? Why? Why do they need to care? What's a HasCallStack? Keep in mind they<br>
> don't know types, typeclasses, or anything else.<br>
><br>
>> that the expression needs a call-stack<br>
><br>
> Still don't know what a call, stack, or call-stack are.<br>
><br>
>> because it might crash.<br>
><br>
> Why does that change the type? We can construct bottoms like `let x in x`<br>
> that crash the program without changing the type.<br>
><br>
>> >So HasCallStack => [Integer] is a [Integer]<br>
><br>
> What makes this even more obnoxious is that when we finally do introduce<br>
> typeclasses and constraints, we talk about constraining a _type variable_<br>
> and now you've baked this magic in they cannot possibly be explained at all<br>
> in the book.<br>
><br>
>> that might crash and produce a stack-trace<br>
><br>
> First bit they might pick up from context, they don't know what a stack<br>
> trace is. Bonus round: when you explain things "from first principles", you<br>
> can't duck the fact that it's actually a call graph when explaining a<br>
> "stack" trace or call stack. Now you have to explain why/how it gets<br>
> flattened from one representation into the other.<br>
><br>
><br>
> Oliver had it when he said,<br>
><br>
>>"What's a call stack?"<br>
><br>
> They don't know what a stack, a call, or the combination thereof is. We had<br>
> planned to address these issues in the (much later) chapters that cover<br>
> profiling and errors. Because that's when they're relevant. This hasn't been<br>
> relevant the entire span of the book. It _never_ mattered that you didn't<br>
> get a stack trace from bottoms. In practice, does it suck? Sure! But they're<br>
> not practitioners yet! I am (I use Haskell for my 9-5 and have done for a<br>
> year and a half) and it still hasn't mattered to me. The only time I've<br>
> really wanted a stack trace is when this mechanism would not have been<br>
> available to me to begin with.<br>
><br>
><br>
> Gamari / amindfv<br>
>> I don't have a copy of GHC 8 atm to test this with: is an expression like<br>
>> this now illegal?<br>
>><br>
>> x :: Int<br>
>> x = undefined<br>
>><br>
>>This is still valid. The change in GHC 8.0 is merely that GHC will infer<br>
>>a CallStack constraint instead of solving it in-place if asked to infer<br>
>>a type for a let binding whose RHS demands a callstack.<br>
><br>
> We have readers use the REPL _a lot_. Not only to load code but also<br>
> free-standing expressions in the REPL when experimenting and learning. Type<br>
> assignment in the REPL is noisy and we have to write around some pretty<br>
> gnarly width limitations (40-60 cols). This breaks the examples where we're<br>
> combining bottom and type inference to explore how terms and types interact.<br>
><br>
> I am less disturbed by `HasCallStack =>` than I was by the inferred type of<br>
> ($).<br>
><br>
><br>
> I know designing around pedagogical limitations like this is tedious but<br>
> imagine doing it for 900-1,200 pages (formatting varies) of tutorial and<br>
> exercises, then getting unpleasant surprises right as the book is about to<br>
> be done.<br>
><br>
><br>
> Sorry about the messy thread all.<br>
><br>
><br>
> [1]: <a href="http://haskellformac.com/" rel="noreferrer" target="_blank">http://haskellformac.com/</a><br>
><br>
><br>
> On Sat, Feb 13, 2016 at 1:48 PM, Bryan Richter <<a href="mailto:b@chreekat.net" target="_blank">b@chreekat.net</a>> wrote:<br>
>><br>
>> On Sat, Feb 13, 2016 at 09:18:07AM -0800, Eric Seidel wrote:<br>
>> > Here's what the GHCi session should look like.<br>
>> ><br>
>> > > $ ghci<br>
>> > > GHCi, version 8.0.0.20160204: <a href="http://www.haskell.org/ghc/" rel="noreferrer" target="_blank">http://www.haskell.org/ghc/</a> :? for help<br>
>> > > Loaded GHCi configuration from /home/callen/.ghci<br>
>> > > Prelude> let myList = [1..5 :: Integer]<br>
>> > > Prelude> let myList' = myList ++ undefined<br>
>> > > Prelude> :t myList'<br>
>> > > myList' :: HasCallStack => [Integer]<br>
>><br>
>> What use case is satisfied by providing this information? How does it<br>
>> benefit the Haskell programmer? How do I use it?<br>
>><br>
>> _______________________________________________<br>
>> Haskell-Cafe mailing list<br>
>> <a href="mailto:Haskell-Cafe@haskell.org" target="_blank">Haskell-Cafe@haskell.org</a><br>
>> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
>><br>
><br>
><br>
><br>
> --<br>
> Chris Allen<br>
> Currently working on <a href="http://haskellbook.com" rel="noreferrer" target="_blank">http://haskellbook.com</a><br>
><br>
> _______________________________________________<br>
> Haskell-Cafe mailing list<br>
> <a href="mailto:Haskell-Cafe@haskell.org" target="_blank">Haskell-Cafe@haskell.org</a><br>
> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div><div dir="ltr"><div><div dir="ltr"><div dir="ltr">Chris Allen<br><div><span style="font-size:12.8000001907349px">Currently working on </span><a href="http://haskellbook.com" target="_blank">http://haskellbook.com</a></div></div></div></div></div></div>
</div>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr">Chris Allen<br><div><span style="font-size:12.8000001907349px">Currently working on </span><a href="http://haskellbook.com" target="_blank">http://haskellbook.com</a></div></div></div></div></div></div>
</div>