Re: additions

[Mike Stay <metaweta@gmail.com>]

2009/12/25 Carsten Führmann <c.fuhrmann@bath.ac.uk>:
> I used the term "functional [programming] language" on purpose (as
> opposed to "functional programming style"), because of your statement
>
>> So there's not a lot of call for learning a functional programming
>> language either.
>
> which I feel might be wrong.

OK, I worded that badly.  I think there are lots of reasons to learn
functional programming, and once you're doing functional programming,
then you need to learn category theory to do it well.

Most of the code we've got is not functional, and the languages we
work with make it hard to use higher-order functions and closures.  So
there's some resistance to overcome in convincing people to use
functional style.

> I meant that JavaScript is a functional
> programming language in the same way in which ML/OCaml/F#, Lisp, and
> Scheme are (just uglier, slower, and running in a sandbox called
> "browser"). These are considered functional languages by many, and
> their categorical semantics has been studied. (Well, the semantics of
> idealized versions.)  JavaScript is just riddled with some syntactic
> and semantic ugliness that makes it unattractive for formal study, but
> that doesn't make it un-functional in principle.

The syntax of those languages certainly encourages functional
composition over imperative programming, and they make it easy to
construct closures and higher-order functions.  However, none of them
are purely functional like Haskell.  I suppose I don't see the point
of making the distinction between functional and imperative unless you
really can't cause side-effects.

>> I'm not sure what you mean by "the whole monad business does not
>> apply".  There are lots of monads, each doing something different.
>> There are several monadic parsers I know of in JavaScript, for
>> instance.  Here's a monad for making JavaScript be lazily evaluated
>>instead of eager:
>>  function e(x) { return function() { return x; } }
>>  function m(x, y) { return function () { return x()(y()); } }
>
> Doesn't very fact that JavaScript allows you to write down the
> delaying monad give away its functional-language nature? And doesn't

I could write down the delaying monad in Java, too, but it would be
much larger.  If the only feature you require of a functional language
is that the syntax makes it *possible* to create closures, then nearly
any programming language will fit the bill.  If it has to be easy,
then Java and C/C++ are not functional, while Scheme, ML, JavaScript
and Perl are.  On the other hand, if you say that it should be hard to
use the imperative style in a functional language, then Scheme and ML
are functional, while Perl and JavaScript are not.

> the existence of monadic parsers in JavaScript underpin that it might
> be beneficial for real-life programmers to learn some functional
> programming?

Sure.  See above.

> By "monad business" I meant using monads to introduce side effects to
> lazy languages like Haskell, I could have been clearer there.
>
> Categorically, your monad is of a different kind, as I shall now
> sketch. (Just in case anyone is interested.)

Thanks, that _was_ interesting!

I suppose what I'm really looking for is cool algorithms like the one
described in Backhouse's paper "Fusion on Languages" (thanks, Neel!)
where they either wouldn't have been discovered without category
theory, or where category theory is the only decent way to understand
the algorithm.

> Happy holidays,
>   Carsten

Thanks!  To you, too.
-- 
Mike Stay - metaweta@gmail.com
http://math.ucr.edu/~mike
http://reperiendi.wordpress.com


[For admin and other information see: http://www.mta.ca/~cat-dist/ ]