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
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.