Re: Practicality of functional and logic languages?

eifrig@beanworld.cs.jhu.edu (Jonathan Eifrig)
Tue, 12 Jan 1993 00:43:17 GMT

          From comp.compilers

Related articles
Practicality of functional and logic languages? benes@dcse.fee.vutbr.cs (Mirek Benes) (1993-01-11)
Re: Practicality of functional and logic languages? eifrig@beanworld.cs.jhu.edu (1993-01-12)
Re: Practicality of functional and logic languages? tobbe@erix.ericsson.se (1993-01-12)
Re: Practicality of functional and logic languages? maniattb@cs.rpi.edu (1993-01-12)
Re: Practicality of functional and logic languages? torbenm@diku.dk (1993-01-13)
Re: Practicality of functional and logic languages? hdev@dutiai.twi.tudelft.nl (1993-01-13)
Practicality of functional and logic languages? lock@karlsruhe.gmd.de (1993-01-14)
Re: Practicality of functional and logic languages? nickh@CS.CMU.EDU (1993-01-14)
[4 later articles]
| List of all articles for this month |

Newsgroups: comp.compilers
From: eifrig@beanworld.cs.jhu.edu (Jonathan Eifrig)
Organization: The Johns Hopkins University CS Department
Date: Tue, 12 Jan 1993 00:43:17 GMT
References: 93-01-059
Keywords: functional, design

Mirek Benes <benes@dcse.fee.vutbr.cs> writes:
>I would like to know some opinions concerning functional and logic
>programming languages (Haskell, Miranda, ML / Prolog) and their practical
>usability for programming:
>
>* Are they (1) toys for playful programmers, (2) something usable only
> at universities for never-ending research, or (3) important means for
> development of usable software products?


Hoo boy! Sounds like flame bait to me! :-)


"Yes, Virginia, there is a Santa Claus," or in this case practical
uses for "non-procedural" languages:


1) Most expert system shells that I've seen have been written in
Lisp. Now, Common Lisp is a "functional language" only in the
broadest possible interpretation of the definition, but since
it supports first-class function abstractions it certainly isn't
a "procedural language."
2) I know of at least two financial brokerage houses that use
Smalltalk extensively for financial and economic simulations.
Granted, Smalltalk isn't an example of either a functional or
a logic programming language, but the fact remains that people
sometimes _do_ use goofy programming languages in certain
environments.
3) The Japanese tried to use Prolog as the basis for their much-
ballyhooed "Forth Generation Computer" project. Granted, this
never really got anywhere, but, hey, they tried! :-)
4) ML wasn't originally intended as a general-purpose programming
language _per_se_, but rather as the metaprogramming language
for the PCF theorem-prover. As such, it was used as a _tool_
for some very interesting programs. Currently, Isabelle, a
very interesting theorem-prover, is written completely in ML.
5) The SML/NJ compiler, the _de_facto_ standard implementation of
ML in the United States, is written almost completely in ML
itself (with a few bits of C code for the garbage collector
and other run-time junk.) While this of course seems a little
incestuous, the compiler was written in ML precisely _to_
demonstrate the feasiblity of writing very large programs within
ML. By any metric, the SML/NJ compiler has to be considered
an important example of a "useable software product."


I think the jury is still out with respect to which features of
these more experimental languages are going to migrate to more mainstream
languages; that is, after all, the purpose of research! However, I think
it's very safe to say that the following language features will be showing
up in more "mainstream" use in the near future:


1) A garbage-collected heap for non-system programming tasks. It's
just too hard for programmers to keep track of the necessary
extent of persistent data structures in large systems.
2) User-defined recursive data structures, along the lines of
ML's "datatype" declarations. This, along with the related
notion of function-definition-via-pattern-matching, is simply
too elegant and expressive to not catch on. Tree-oriented
algorithms are so easy to implement and understand when one
doesn't need to fool around with pointers explicitly.
3) Some sort of parametric polymorphism in code modules. The
future is still murky in this area, especially with respect to
the combination of reference cells and polymorphism, but
you're certainly going to see more than just Ada's generic
packages in the future.
--
Jack Eifrig (eifrig@cs.jhu.edu) The Johns Hopkins University, C.S. Dept.
--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.