🚀 go-pugleaf

>I'm in favor.  Indeed, I was surprised that there wasn't such a group
>already.  The only problem would be if we later wanted a ML group,
>say.  Should it have to be comp.lang.functional.ml?
No.  Whilst we may hope that comp.lang.functional would encourage extra
discussion on functional langauges, it seems plausible to me that it
will settle down to a steady state of having some fraction of the traffic
on comp.lang.misc - hardly enough to justify a new group.  Also, there is
already a mailing list devoted to sml, and it wouldn't justify a new group
either.

In any case, most of the discussion on sml-list revolves around ambiguities
in semantics for various constructs.  Whilst some of these are purely sml
specific, others are more general in scope: what do you want in a module
system in a functional language, for example?  People from other functional
language backgrounds might well usefully contribute to such discussion.

I am in favour of comp.lang.functional but not comp.lang.functional.xxxx.


/ otter:comp.lang.misc / dorai@helma.rice.edu (Dorai Sitaram) / writes:
> I'm tentatively in favor too; however, "functional" is about the most
> ambivalent, and consequently useless, term in programming languages.
Fooey!  Computer science abounds with - nay thrives on - ambiguous terms.
Consider: is "functional" less ambiguous than, say, "user-friendly" or
"fourth generation"?  The term "functional" *is* unfortunate in being
overloaded with "posessing functionality" and "pertaining to functions",
however, but I submit that this is easily resolved by context.

A functional language, as the term is commonly used, has as its primary
representation formalism pure, typed or untyped lambda calculus.  For
better or worse, some functional languages supplement the pure lambda
calculus with imperative constructs, for purely pragmatic reasons.

> The two common (often incompatible) views seem to be
> i) A language which has higher-order functions;
Most implementations of the lambda calculus allow fist class functions,
and are therefore higher order.

> ii) Ditto, but which very definitely eschews "assignment."
A language which eschews imperative constructs (ie side effects) is
referentially transparent.

These two features are orthogonol: you can have none, one or both in a 
language and neither entails the other.

> Thus we have the paradox of Scheme and ML being both "imperative"
> ("non-functional," taking definition ii)) as well as "functional"
> (taking definition i)).
Scheme and Sml have *useful* purely functional, higher order core notations,
and imperative extensions.  You can choose to write an imperative program
in either, but you don't have to.  Mostly, programs are better off for
being purely functional.

> --dorai
Ian.

!Ian Dickinson,     HP Labs, Information Systems Centre,      Bristol, England!
!net:    ijd@hplb.hpl.hp.com        !                                         !
! or:    ijd@hplb.uucp              !The unification of mind, body and spirit:!
!These opinions are all my own work.!   ?-  mind(X),  body(X),  spirit(X).    !