Tell me more ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.
up vote 7 down vote favorite

Are there any 100% pure languages (as I describe in the Stack Overflow post) out there already and if so, could they feasibly be used to actually do stuff? i.e. do they have an implementation? I'm not looking for raw maths on paper/Pure lambda calculus. However Pure lambda calculus with a compiler or a runtime system attached is something I'd be interested in hearing about.

share|improve this question
1  
TL;DR. btw when a question get's closed on StackOverflow, it will probably get closed here. If it did fit Programmers, it would get migrated here instead. – Yannis Rizos♦ Nov 22 '11 at 8:54
6  
To get an answer you might want to shorten down the context description to a minimum (now it looks like a blog post) and leave the last paragraph. You could also link to a discussion somewhere else. – l0b0 Nov 22 '11 at 9:00
3  
@ThelronKnuckle, insulting the people of whom you're asking a question probably won't invite a warm reception. It's not about poor attention spans. It's about writing a question that doesn't waste the reader's time. Condense your question to its essence. – Frank Shearar Nov 22 '11 at 9:26
1  
@TheIronKnuckle I spend an hour writing a compiler in javascript, its lying around on a jsfiddle somewhere, seriously write one yourself, it's trivial. Other then that just use this one – Raynos Nov 22 '11 at 10:44
1  
@TheIronKnuckle for reference I found that fiddle – Raynos Nov 22 '11 at 11:16
show 7 more comments

4 Answers

up vote 17 down vote accepted

Indeed, as Simon Peyton Jones once stated, Haskell is the finest imperative language out there.

Seriously, purity is not a religious issue. The problem is not that impure functions and mutable data exist. The problems in conventional languages is that often you can't tell impure frm pure and mutable from immutable: not by looking at it, not by compiling it, only by running it.

This is the great advantage that Clean, Haskell (and followers like Frege) have. Conversely, languages like F#, Scala or Clojure that embrace the imperative world and just add the possibility to build something functional alongside suffer from the same problems as the imperative languages, although they may seem very practical indeed.

share|improve this answer
Haha, he actually said that? Interesting perspective – TheIronKnuckle Nov 22 '11 at 9:39
Another worthwhile perspective - Monads in Haskell get some syntactic sugar, but the basic construct is just a kind of abstract algebra - Monads can be (and have been) used in other languages including Objective CAML and even Javascript IIRC. So arguably, no language can be purely functional - the functional building blocks allow imperative programming (in monadic form) to be provided as a library. – Steve314 Nov 22 '11 at 10:49
But when you dig into it there's no implicit state or side-effects in the monads, so what looks like impure code is deceptively pure :P Hell, with continuations you can get even get purified goto (in a sense); – TheIronKnuckle Nov 22 '11 at 11:32
1  
I am working on a short e-book on JavaScript Monads for O'Reilly, it should be out early next year. – Zachary K Nov 22 '11 at 14:05
even C++ compilers have mechanism available to compile-time check for side effects. (hint, it's const) But normally that's not enough, since an elephant can run through the stuff that doesn't do the check. – tp1 Nov 22 '11 at 16:51
up vote 6 down vote

It seems to me you're trying to reinvent Haskell.

The language doesn't need to have side effects at all. The run-time system does. The compiler/run-time system simply needs to search for the main function and treat it as an entry-point to the program as a whole.

Nice description of how IO is done in Haskell.

Hell, maybe you could execute until you need to prompt the user, wrap up the remainder of the code as a completely new program in the return type

You mean monads?

>>= :: M a -> (a -> M b)

After the first half (M a) prompted the user to provide data (of type a), the second half (a -> M b) is the the "remainder" you describe.

If Haskell allowed you to introspect functions instead of just allowing you to run them, it would also be homoiconic.

share|improve this answer
"It seems to me you're trying to reinvent Haskell." Haha, I've been slowly realising that over the past 6 or so hours. Should I be proud or slap myself for proposing to reinvent the wheel? :P – TheIronKnuckle Nov 22 '11 at 12:51
up vote 5 down vote

I would regard Haskell as 100% pure. And it can certainly get stuff done.

While there are some good debates about what "100% pure" actually means, it is certainly not true that a pure functional language cannot do IO. See also the comp.lang.functional FAQ.

All you have to do to allow IO in a pure language is pass a parameter that represents the state of the world to the program, and return the state of the world as an output. This program has no side effects, is referentially transparent and counts as 100% pure. This is pretty much what Haskell's IO Monad does under the hood.

A special mention perhaps for Clojure, which is definitely a practical language with the entire JVM ecosystem and toolchain to your fingertips. It is clearly not 100% pure (since you can get side effects via the STM managed references, various IO functions or Java interop). However the core language if you avoid these special cases is purely functional. So if you stick to the pure subset of Clojure, you actually have a pretty decent pure functional language for most purposes.

share|improve this answer
Re: "This program has no side effects, is referentially transparent and counts as 100% pure", this only holds if we ascribe a whole lot of extra meaning to the RealWorld# baton passed between IO actions. In reality, it's just a token, so it is not a ticket to referential transparency of IO actions. The argument gets even weaker in the presence of threads, since now each thread has a RealWorld#, and who's to decide which one is "accurate"? – Adam Nov 22 '11 at 15:10
up vote 3 down vote

A "pure" language that couldn't do IO couldn't do much. ...after all, even printing a result on the screen is IO. So if you can't see the result of a program, wouldn't it be rather pointless?

You couldn't read files, couldn't listen to sockets, couldn't interact with users, couldn't ask for input... etc. What good would that be?

That said, Haskell is the closest to "pure" (whatever that means) functional programming I know of. Their whole IO system is even made using Monads, which kind of a mix between IO and functional.

I also know of "Clean" which is an academic functional language and sees IO as a transform of a World object if I remember right ...however, this starts to be very exotic.

share|improve this answer
-1 because pure does not mean "no IO". Pure functional langauges like Haskell can do IO - one way of doing this is by passing a parameter that represents the state of the world to a function that represents a "task". See Haskell's IO monad for example..... – mikera Nov 22 '11 at 10:11
@mikera - but even SBC (who was at least a main designer of Haskell and also one of the implementers of GHC) recognises monadic code as impurity. Controlled impurity, with side-effecting code marked out explicitly and a clean separation of side-effecting and non-side-effecting code, but still impure. Basically, Monads show that impurity can be created from pure ingredients. – Steve314 Nov 22 '11 at 10:53
@Steve314 I think it comes down to definitions :-) If you take pure to mean "referentially transparent/no side effects" then you can never built impure functions with pure functions. If you take impure to mean "in an imperative style" then I certainly agree that you can use monads to construct something that behaves in an imperative fashion. – mikera Nov 22 '11 at 11:23
1  
tbh I don't see monads as having much to do with it at all. The IO monad is not special, it's just a way of dealing with the IO that is happening somewhere completely different. Outside the scope of the language + program. I've never tried, but I'm guessing you can still run a haskell program and turn off the side effects in the run time system; you don't have to change your code at all. All those dasterdly monads will remain. The end result will be a pure IO action that never did anything. This shows how side effects happen outside the language. Monads just help to control them – TheIronKnuckle Nov 22 '11 at 11:30
@mikera - I don't think my previous comments were clear, so I'll try another approach. When a politician is less than transparent, a common approach is to bury the relevant in a mass of the irrelevant. Giving an explicit name to the entire mass of relevant and irrelevant doesn't remove the referential opaqueness. And this does happen in functional programming - a value passed to a function is quite often a mass of irrelevance along with a few relevant details. Passing "the world" to a function when only a few aspects of the world are relevant is an obvious example of referential opaqueness. – Steve314 Nov 22 '11 at 12:24

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.