On 02/10/2016 02:59 PM, Raphael Gaschignard wrote:
I think the "show a simple type, then the 'real' type " solution is pretty good ( especially since you need to be doing type level programming to hit issues where the simple type doesn't hold anyways)
It *might* work, but it needs to be *EXTREMELY* clear (visually and perhaps otherwise) in the documentation that is lying to -- ehm, I mean simplifying for -- you. Scala went with the same idea of lying (they call it the "use case") in the documentation of some of their collection method signatures and I can tell you from personal experience that it can be absolutely *infuriating* to have worked on trying to understand an error based on the documentation only to realise that what the compiler checks and what the documentation shows you isn't the same thing. Incidentally Java had a similar issue with the whole public class Foo { public static void main(String[] args) { } } incantation being needed to teach beginners the first thing about Java. You know what I did -- I just said "yeah, just ignore that bit, I'll explain when you're ready" and it wasn't actually a problem in practice. Turns out people are quite at ignoring things they don't understand as long as you *tell them* to just ignore it until later. (Also, remember that this is *one* symbol we're talking about, albeit a relatively common one. You could just *avoid* it entirely in teaching material if you so desire.) Regards,