Mon Mar 11 09:31:40 EDT 2019
Monads are too cumbersome for pure languages
The main problem is that in order to capture sharing information, it
is necessaary to use a monadic form. That, however, is very
cumbersome for languages that are mainly in expression form.
As of now I've seen only a couple of ways to work around this:
- Use a different syntax (template haskell or explicit compilation)
- Compiling to categories (similar, but at the lambda<->ccc level)
- Some hack that violates referential transparency
The simplicity of just sticking to Haskell is an advantage, but it
makes the language ugly at the lower levels. Maybe just get used to
Specifically for and & or in the HDL: maybe there is a way to do just
that? E.g. use some kind of list representation.
a = ~b | c | d
a <- or [ not b, c, d ]
When using list, they all need the same types. It can be done using
tuples though, and using only binary tuples, implementing a class for 3 instances:
(a, a) (a, m a) (m a, a) (m a, m b)
a <- or (not b, or (c, d))
This is pretty much equivalent to just having 2-ary functions, and
there I ran into ambiguities that required a lot of type annotation.
There doesn't seem to be a way out.
Another way is to have a sub-language for just the logic:
app $ Or [Not [Or [a,b,c]]]
But then this would need to be extended for every function.
How to make this workm where each operation is a uniary or a binary.
x or [x not [x or [a,b,c]]]
I think that would work.
Same using an infix
or $$ [not $$ [or $$ [a,b,c]]]
Forget about the unary for now. The binary form isn't that hard to
express. Nope... doesn't work!
Forget about this... There is no solution apart from creating a data
structure representing the sub-language, and compiling it explicitly.
Get used to monadic notation.