[Haskell-cafe] If you'd design a Haskell-like language, what would you do different?

Ben Lippmeier benl at ouroborus.net
Tue Dec 20 12:59:39 CET 2011


On 20/12/2011, at 21:52 , Gregory Crosswhite wrote:
> 
>> Some would say that non-termination is a computational effect, and I can argue either way depending on the day of the week.
> 
> *shrug*  I figure that whether you call _|_ a value is like whether you accept the Axiom of Choice:  it is a situational decision that depends on what you are trying to learn more about.

I agree, but I'd like to have more control over my situation. Right now we have boxed and lifted Int, and unboxed and unlifted Int#, but not the boxed and unlifted version, which IMO is usually what you want.


>> Of course, the history books show that monads were invented *after* it was decided that Haskell would be a lazy language. Talk about selection bias.
> 
> True, but I am not quite sure how that is relevant to _|_...

I meant to address the implicit question "why doesn't Haskell use monads to describe non-termination already". The answer isn't necessarily "because it's not a good idea", it's because "that wasn't an option at the time".


> Dec 20, 2011, в 14:40, Jesse Schalken <jesseschalken at gmail.com> написал(а):


>> Including all possible manifestations of infinite loops?
> 
> So... this imaginary language of yours would be able to solve the halting problem?

All type systems are incomplete. The idea is to do a termination analysis, and if the program can not be proved to terminate, then it is marked as "possibly non-terminating". This isn't the same as deciding something is "*definitely* non-terminating", which is what the halting problem is about. This "possibly non-terminating" approach is already used by Coq, Agda and other languages.

Ben.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20111220/1f307744/attachment.htm>


More information about the Haskell-Cafe mailing list