[Haskell-cafe] Non-deterministic function/expression types in Haskell?
Benjamin Redelings
benjamin.redelings at gmail.com
Fri Jan 12 16:38:48 UTC 2018
Hi Oleg,
On 01/11/2018 09:17 AM, Oleg Grenrus wrote:
> Hi Benjamin
>
> Let's see what you ask for, you have *new* syntax for types:
>
> a[N] and a[D]
>
> what are a[N][N] or a[N][D] or a[N][D] or a[D][D]?
>
> Aren't they a[N], a[N], a[N] and a[D] respectively?
> That's what monads are about!
Just to be clear, I'm not using [N] as an operator on types, but as part
of the type. So a type could be something like the pair (Int,D) or
(Int,N). In that context a[N][N] is not part of the system.
>
> So
>
> a[N] ~ Distr a
> a[D] ~ Identity a ~ a
>
> No need to complicate type-system! You just to not be afraid of monads!
>
> Monads aren't sequencing, they are computational context.
>
> I guess, you just want more natural term-level syntax.
>
> You can use ApplicativeDo [1] (in GHC-8.0+), so e.g.
>
> do x <- normal 0 1
> y <- normal 0 1
> return (f x y)
>
> will be transformed into
>
> liftA2 f (normal 0 1) (normal 0 1)
>
> That's almost like
>
> f (normal 0 1) (normal 0 1)
>
> if you have proper syntax highlighting ;)
>
> Note: various term syntax extensions been proposed.
> E.g. idiom brackets in the "Applicative programming with effects" [2]:
>
> (| f (normal 0 1) (normal 0 1) |)
>
> to mean
>
> pure f <*> normal 0 1 <*> normal 0 1
>
> which is equivalent to above liftA2 expression. If you like that, you
> can check
> "the Strathclyde Haskell Enhancement", it supports idiom brackets.
In my other message I posted an example that doesn't fit this very well:
do { x <- f x } does not work, where as let x = f x does work. Basically
I'm trying to avoid monads because I want to use the full features of
the Haskell language, instead of programming in an embedded language.
In that context "more natural" term-level syntax is not sufficient.
Also, it seems possible that everything in Haskell COULD be written in a
monad. We could eliminate recursive let bindings, and tell people to
create a giant state machine which they use by reading and writing
IORefs. But then you also eliminate some of the point of using Haskell
and may as well go write in C or something. So it seems to me that just
because you CAN use a monad doesn't mean you SHOULD use a monad, and the
question is "when is a monad better than something else?"
Does that make sense? Am I missing something?
-BenRI
More information about the Haskell-Cafe
mailing list