[Haskell] Mixing monadic and non-monadic functions

[ozone at algorithm.com.au]

On 24/03/2004, at 9:54 AM, Sean E. Russell wrote:

>> We'd all love to make the lifting implicit, but no one knows how to 
>> do it
>> without breaking the whole language.
>
> I've heard people talk about the functional "purity" of Haskell -- 
> you'd have
> to break this purity to add implicit lifting?

I don't think you would break the functional purity of Haskell if you 
did such a thing, but you'd probably need some new syntax to help out 
the type system.  Perhaps something like:

     assertBool "fail" $ length (<somefunc a>) == length (<somefunc b>)

So here, (<a>) performs the same function as the <- operator, but 
assigns the result to an "anonymous variable" and is instantly consumed 
by whatever function uses its value.  Please don't berate me for my 
choice of syntax, by the way: that was just an example :).

One problem with this is that you now don't know what order those two 
operations take place: does "somefunc a" run first, or does "somefunc 
b" run first?  You have this same problem in other imperative languages 
too; I'm not sure if, e.g. C defines an order for function evaluation 
to occur.  Perhaps you could just dictate a left-to-right order, or 
maybe come up with bizarre (<1 ... >) and (<2 ... >) constructs to 
indicate what order things should run in.  Some ideas to get started, 
anyway.

I do agree with you that not having syntactic sugar to do something 
like that is somewhat inconvenient, and it would be a nice addition to 
the language.

>> A related problem which was discussed here recently is Haskell's lack 
>> of
>> per-type namespaces, something which even C programmers take for 
>> granted.
>> Again, the problem is the tricky interaction with type inference.
>
> Augh!  Yes!  I've hit that as well.  Well, in my case, it was 
> constructors.  I
> was trying to do:
>
> 	data Effort = Easy | Middle | Hard
> 	data Impact = Low | Middle | High

Perhaps one option for this would be to have explicitly quantified data 
namespaces, so that you would have to write 'Effort.Middle' to 
construct something of type Effort, and 'Impact.Middle' to construct 
something of type Impact.

The problems you mention of in Haskell are certainly solvable: it's 
just the mere matter of implementing such features ... :)  I think the 
Haskell community (at least, the community who are capable of making 
such changes to the Haskell implementations) is unfortunately a bit too 
small to put such syntactic niceties in the language; we simply don't 
have enough human resources to do it.  But I'm sure plenty of others 
would agree that those features would be nice!


-- 
% Andre Pang : trust.in.love.to.save