Re: terminology

Marshall wrote:
> Yeah, Haskell has had a significant influence on my thinking.
> Another book on my shelf (on that I've actually read all the
> way through) is "Haskell: the Craft of Functional Programm"
> (Thompson.) Although I'm not a fan of monads or laziness.
>

With that last sentence, you move to iffy territory ... especially on laziness. Laziness allows you to deal with infinite data structures with impunity, evaluating them as far as is actually needed once and once only. (Laziness appears in some imperative/referentially opaque languages like C in the limited guise of short-circuit evaluation; although, if your program depends on side effects you might get some surprises if one of your functions doesn't get evaluated...)

[ snippage ]

> Although I think SML doesn't always get the credit it deserves.

No, I think Standard ML is fairly well lauded; it's just that head-on FP fans are heading to the lazily evaluated languages now.

> Sure it's "impure" but I think ultimately that's a real advantage.
> It lets you be as pure as is appropriate to the task at hand.

Nope; monads let you do that in a far better way. Monads allow you to program sequentially where required, which takes away the last need for side effects - I/O. Because you can't guarantee which order redexes will be reduced, I/O (especially O) is a bit of a gamble, so previously ways had to be found to specifically order these reductions, which usually meant some kind of imperative programming. Monads let you do the same thing in a more FP friendly manner. If you go to haskell.org, there's a couple of good presentations on there about monads, including one called "Tackling the Awkward Squad : monadic input/output, concurrency, exceptions and foreign language calls in Haskell".

> Functional purity increases the ability to reason about code,
> but imperative idioms, for all their *unclean* reputation
> (mostly deserved) allow for some impressive achievements
> in modularity and efficiency.

Actually, efficiency is nowhere near the problem it was; there are surprising similarities between a highly optimised environment-based implementation (the fSECD machines or LISP implementations) and a highly optimised graph reducer implementation (such as the Chalmers G-machine). Peyton-Jones's "Implementation of Functional Programming Languages" might be quite old now (1987/88) but it has a couple of excellent chapters on the G-machine, amongst other things. In terms of modularity, you don't need imperative (or rather, referentially opaque) languages for that - Standard ML has modules, after all. If anything, because you *know* you can't have random side effects, a referentially transparent language would be even better for modular programming.

> There's also the scaring the horses issue you mentioned, and I think purity-or-else
> is likely to make them whinny nervously, whereas purity
> by default with an option to escape is much more
> palatable.
>

But that palatable option brings with it some unpalatable side effects (that is a truly awful pun - sorry).

>
> > Most of the rest of it has just been fiddling with Algol-60.
>
> Ain't that the truth! And wasn't it "an improvement on most
> of its successors" after all?!
>

Wasn't that Pascal ? Pascal's successes were to remove some of the baroque excesses of Algol-60 and (I think) introduce enumerations; records (of a sort) were introduced earlier (in Algol-W or Algol-65, depending on reference, after Wirth jumped the Algol-68 ship) and I think they dumped the lunacy of call-by-name there too, but there were still some very odd features in Pascal (variant records, anyone ?)

> Rather than Snobol I'd cite Icon, as the more developed and therefore
> more interesting of the two. (Both by Ralph Griswold.) I've not played
> with APL but I have read a fair bit about J and K, which derive from
> APL, and they're quite an achivement.
>

Yes, although for most of us the influence has arrived indirectly. If only they had designed the original APL to use normal keyboards, things might have been so much different ...

> But the real Mother Tongue is Lisp; like Latin, every idea has
> already been tried there; like Latin, it is worthy of respect and
> study, though I wouldn't want to have to use it for anything.
>

Well, yes and no. The real mother tongue is of course the lambda calculus, and you definitely wouldn't want to program in that in the raw. But I have seen some excellent work done in LISP in knowledge engineering, and anyone who fell in love with their Symbolics workstation will queue up to berate you at length as to how usable they were (although I hated them, and called the one I did have to use the "Shambolics"). But you still have side effects in many implementations, and that's enough for me to look elsewhere. (As anyone who reads my posts will know, I'm not afraid of (Lots of (Irritating) (Stupid (Parentheses)))). Received on Mon Jun 19 2006 - 13:00:23 CEST