<br><br><div class="gmail_quote">On Sat, Jun 26, 2010 at 12:27 AM, Jason Dagit <span dir="ltr">&lt;<a href="mailto:dagit@codersbase.com">dagit@codersbase.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br><br><div class="gmail_quote"><div class="im">On Sat, Jun 26, 2010 at 12:07 AM, Andrew Coppin <span dir="ltr">&lt;<a href="mailto:andrewcoppin@btinternet.com" target="_blank">andrewcoppin@btinternet.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>wren ng thornton wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
And, as Jason said, if you&#39;re just interested in having the same programming style at both term and type levels, then you should look into dependently typed languages.<br>
</blockquote>
<br></div>
Out of curiosity, what the hell does &quot;dependently typed&quot; mean anyway?</blockquote><div><br></div></div><div>The types can depend on values.  For example, have you ever notice we have families of functions in Haskell like zip, zip3, zip4, ..., and liftM, liftM2, ...?</div>

<div><br></div><div>Each of them has a type that fits into a pattern, mainly the arity increases.  Now imagine if you could pass a natural number to them and have the type change based on that instead of making new versions and incrementing the name.  That of course, is only the tip of the iceberg.  Haskell&#39;s type system is sufficiently expressive that we can encode many instances of dependent types by doing some extra work.  Even the example I just gave can be emulated.  See this paper:</div>

<div><a href="http://www.brics.dk/RS/01/10/" target="_blank">http://www.brics.dk/RS/01/10/</a></div><div><br></div><div>Also SHE:</div><div><a href="http://personal.cis.strath.ac.uk/~conor/pub/she/" target="_blank">http://personal.cis.strath.ac.uk/~conor/pub/she/</a></div>

<div><br></div><div>Then there are languages like Coq and Agda that support dependent types directly.  There you can return a type from a function instead of a value.</div></div></blockquote><div><br></div><div>I just realized, I may not have made this point sufficiently clear.  Much of the reason we need to do extra work in Haskell to emulate dependent types is because types are not first class in Haskell.  We can&#39;t write terms that manipulate types (type level functions).  Instead we use type classes as sets of types and newtypes/data in place of type level functions.  But, in dependently typed languages types are first class.  Along this line, HList would also serve as a good example of what you would/could do in a dependently type language by showing you how to emulate it in Haskell.</div>
<div><br></div><div>Jason</div></div>