[Haskell-cafe] Non-deterministic function/expression types in Haskell?

[Benjamin Redelings]

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