
Typesafe Neural Networks in Haskell with Dependent Types - KirinDave
https://blog.jle.im/entry/practical-dependent-types-in-haskell-1.html
======
pron
I didn't read this closely, but are those dependent types or just type-level
integer literals? Can you use variables and/or arithmetic operations on the
type index? If you can't instantiate the type with non-literals, then these
aren't dependent types. Dependent types are types that _depend_ on (i.e., the
type constructors are functions of) actual _values_ of the language, not types
that are parameterized by other _types_ (even if the syntax allows naming a
type '42', which just _looks_ like a value).

~~~
whateveracct
GHC Haskell type-level Integer literals can constructed from non-literal just
fine :)

[https://hackage.haskell.org/package/base-4.7.0.2/docs/GHC-
Ty...](https://hackage.haskell.org/package/base-4.7.0.2/docs/GHC-
TypeLits.html#v:someNatVal)

There are type-level operators as well for arithmetic, but in my experience
it’s a bit less pleasant than working with Peano Nats.

~~~
pron
And can you say that a type is indexed by, say, an even number? How do you
prove that?

~~~
whateveracct
With TypeLits, idk if that’s possible without some cheating. But that’s
because (as the module name implies) these are type literals and mostly
focused on having Integers that can go from type to term and vice-versa.

I can definitely do that with Singleton peano Nats pretty easily. I’ll end up
with a function of type

    
    
      SNat n -> Maybe (IsEven n)
    

Where IsEven n is some structural proof of even-ness

    
    
      data IsEven (n :: Nat) where
        ZEven :: IsEven Z
        SEven :: forall (n ::Nat). IsEven n -> IsEven (S (S n))
    

I wrote this on my phone, but I’m sure it’s possible and kinda easy to work
with at that.

------
eru
Yet another step in the direction of bringing typed functional programming and
machine learning together. Nice!

------
vog
Very good example and motivation for dependent types.

However, I think it makes strange assumptions on its readership. For example:

 _> If you’re a non-Haskell programmer, this might all seem perfectly fine and
normal, and you probably have only a slightly elevated heart rate. If you are
a Haskell programmer, you are most likely already having heart attacks._

Well, for a non-Haskell programmer, the Haskell code snippets make very few
sense, simply because they are not used to the syntax. And those non-Haskell
programmers who are used to the ML-syntax are programming in SML, OCaml or F#,
which all have a similar type system to Haskell's, and hence do get "elevated
heart rate".

If this article is really meant to be readable by non-Haskell programmers, the
example code snippets should also be provided in a more mainstream language
with static types, such as C++, Java or perhaps JavaScript+TypeScript.

~~~
Tehnix
>Well, for a non-Haskell programmer, the Haskell code snippets make very few
sense, simply because they are not used to the syntax

I didn't take that remark to be anything about the syntax, but rather how
unsafe the code is, since we are dealing with matrices that have assumptions
on their dimensions, essentially leaving the bugs for runtime — he follows
this up with several bullet points explaining why the heart attack :)

~~~
vog
_> I didn't take that remark to be anything about the syntax_

Exactly that's the problem: The author is ignoring the syntax issue, that is,
the fact that the vast majority of non-Haskell programmers won't be able to
make much sense of the the code examples.

------
jdonaldson
The next hoop to jump through would be to specify tape based autograd in a
type system. The type system would not only have to specify the dimensions of
the matrices, but the sequence of operations as well (in order to reverse them
and perform the correct backprop sequence without relying on the runtime).

------
martin1975
Slightly ignorant comment from a Haskell n00b - how does Agda play into this?

