Re: [stack] What does "concatenative" actually mean?
John Nowak <[email protected]>
| Newsgroups | gmane.comp.lang.concatenative |
|---|---|
| Message-ID | <[email protected]> |
On Mar 3, 2009, at 4:35 PM, John Cowan wrote: > John Nowak scripsit: > >> In a concatenative language, one thing you can do as add the 'world' >> to the top of the stack and have all operations work below it except >> those that perform IO. This does let you sort of hand-wave and claim >> the language is purely functional. The problem is that *everything* >> now has a forced evaluation order, not just those things that perform >> IO. In other words, even though your language is purely functional, >> you're still essentially stuck with having to use eager evaluation. >> This is why I claim this approach is mostly hand-waving; it doesn't >> let you do anything different than you otherwise would. > > Nobody ever claimed that Joy was lazy; "pure functional" does not mean > "pure, functional, and lazy". Lazy languages have their virtues, but > so do eager ones. I never claimed anyone ever claimed Joy was lazy. My claim was essentially that, if Joy were purely functional in the same sense Haskell was, you *could* evaluate it lazily if you wanted to. Given that you cannot do so, I don't think it is correct to call it "purely functional". The reason for this is that it does not have the property that you can replace an expression with the result of evaluating it as Haskell does (i.e. referential transparency). Such a property is what enables sensible lazy evaluation. I'm aware eager languages have their virtues. I did after all say I'd prefer Disciple Haskell (which is eager and uses an effect system to control effects instead of monads). > Similarly, it has a type system, just not a static type system. I'll clarify then: You need a static type system to enforce that the world value is used properly. The only possible alternative I can think of is to reference count everything and error if attempting to use the world value when it has more than one reference to it. Unfortunately, this approach is unsatisfactory in a number of ways that I could elaborate on if anyone is interested. - John