[Haskell] Mixing monadic and non-monadic functions
ozone at algorithm.com.au
ozone at algorithm.com.au
Wed Mar 24 11:00:29 EST 2004
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,
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
>> A related problem which was discussed here recently is Haskell's lack
>> per-type namespaces, something which even C programmers take for
>> 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
More information about the Haskell