Dan Bron wrote:
>
> Viktor Cerovski wrote:
>> Let us check out the infamous IO monad,
>> in plain English, and with the minimum use
>> of Haskell and J
>
> That was enlightening (and very well written), thank you. It more or less
> corroborates the view I'd already developed about Monads (i.e. that
> they're
> a way to "stay functional" in a non-functional world), which I tried to
> describe at [1].
>
Thanks!
> And I learned something I like about the IO monad: using it results in the
> same effects, and the code is nearly identical; the only difference is the
> function is decorated, or clearly marked, as IOish (I would say
> side-effecting but if I understand you correctly, that is not true
> anymore).
> I like this; it's similar to the practices I advocated in [2].
>
> But let me ask a devilish question. What if I didn't care about warning
> other programmers that my function was IOish? Other than that caveat,
> what
> has changing the codomain from char to IO chat bought me?
>
Those are important questions. If you define in Haskell that type of f
is Int -> Int, we know it's a pure function that maps integers to integers.
Haskell is rigorous here: this function won't be able to interact with
the outside world---no prints allowed in the definition of f.
Prints are provided *only* with(in) the IO monad.
This means that IO provides a certain set of functions to interact with
the outside world just like, in J, input-output is tucked into the !: conj.
So far there is no difference. Monads, however, also provide an
*environment* within which functions it provides are to be used,
and *only* there. So, if the type of g is Int -> IO Int, it also says
that I'll be able to use g only with(in) IO monad. That's not the case
with other languages, where we still can sprinkle print commands
all over a program.
To turn this argumentation around, we can say that monads do not
provide as general an imperative programming environment as
procedural and OO languages do. Instead, they do provide a way to
define various kinds of imperative/OO looking, feeling and acting
environments each with a purely functional definition and precisely
defined behavior, the price being a sophisticated type system that
must be used.
The environment is defined via >>= and return (bind and lift),
while "do{ }" and "<-" notation is a syntactic sugar.
In the above example, uses of f and g also differ, e.g, we can do:
f :: Int -> Int
f = ....
main = do print (f 10) -- Ok.
because print, provided by IO, accepts type Int. We cannot do:
main = y<-f 10 -- Type mismatch.
print y
because the return type of f is Int, not IO Int. However, we can do
something like:
g :: Int -> IO Int
g = ....
main = do y<-g 10 -- Ok.
print (2*y) -- Ok
because the return type of g, IO Int, is compatible with the type IO a.
In other words, we defined g to work with(in) IO.
Furthermore, there are also types like a b -> a b, i.e a function that
takes an arbitrary parametrization of one type over another (a and b
mean arbitrary types, not necessarily equal) and returns result of that
same type a b.
So, things in Haskell get funky like that pretty quickly, and type
system plays a major role to get the definitions straight and figure out
various ways to pass around and combine things together with
as little trouble as possible.
> The reason I ask is this: this statement more or less aligns with what
> Raul
> said earlier, in [3]: that Monads and Haskell are essentially
> inextricable.
> Now of course the two statements aren't identical: rather than Haskell,
> you
> are identifying a dependency on type systems. But for my purposes, that's
> the same thing.
>
I'm fine with the Raul's and your statement, and, yes, I was making
a finer distinction: LISP has a very general parametric OO classes, C++
has templates, Scheme is purely functional and thus does continuations
but it seems without proper "hiding" mechanism, etc. Those are all
elements similar to parametric types of Haskell and neither of them is
quite like it.
> I say that because as I mentioned in those earlier threads, I'm looking
> for
> a definition or understanding of Monads that can be implemented in J,
> which
> has no type system (or any other functional language which doesn't also
> happen to have an algebra of types).
>
> Also, I'm a bit biased; I have no particular affinity for type systems.
>
> So, my question is really: can Monads be defined independent of a type
> system? If so, can you describe the advantages they'd provide?
>
I don't know of any way that monads can be defined without parametric
types and typed lambda-calculus, and I see no way around them if we
are interested in functional semantics of states, sequential calculations,
encapsulations, side-effects, etc. Thus, I'm also very interested to figure
out how they relate to J. I think I figured out yesterday how this
could be beneficial to J, but first some checks are in order.
You are not the only one biased: apparently Alfonso Church was a big
proponent of typed, while, ironically, Haskell Curry was preferring untyped
(implicitly typed) lambda calculus, so, you're in a good company.
> [1] http://www.jsoftware.com/pipermail/chat/2010-January/002918.html
> [2]
> http://www.jsoftware.com/pipermail/programming/2010-January/017918.html
> [3] http://www.jsoftware.com/pipermail/chat/2010-January/002917.html
>
--
View this message in context:
http://old.nabble.com/Re%3A--Jprogramming--Monads-and-Categories-in-J-tp27213117s24193p27288123.html
Sent from the J Chat mailing list archive at Nabble.com.
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
