Re: Practicality of functional and logic languages? (long)

bromage@mullauna.cs.mu.OZ.AU (Andrew Bromage)
Sat, 16 Jan 1993 04:57:52 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? (long) winikoff@cs.mu.OZ.AU (1993-01-14)
Re: Practicality of functional and logic languages? (long) bromage@mullauna.cs.mu.OZ.AU (1993-01-16)
Re: Practicality of functional and logic languages? (long) bevan@cs.man.ac.uk (1993-01-16)
| List of all articles for this month |

Newsgroups: comp.compilers
From: bromage@mullauna.cs.mu.OZ.AU (Andrew Bromage)
Organization: Computer Science, University of Melbourne, Australia
Distribution: aus
Date: Sat, 16 Jan 1993 04:57:52 GMT
References: 93-01-059 93-01-102
Keywords: functional

maniattb@cs.rpi.edu (Bill Maniatty) writes:
>>What about the power of the functional programming paradigm? Is there an
>>important class of problem which cannot be done by Functional Programming?


winikoff@cs.mu.oz.au (Michael Winikoff) writes:
>... Arrays CAN be done - but unless your language and compiler offers
>support it will be slower.


This, I think, is the bottom line. There is _no_ class of problem which
cannot be solved in a functional language, but the actual implementation
may be very slow and the specification may be cumbersome if the language
does not offer primitive support.


If all else fails, after all, you could always implement an abstract
machine in the language and run on that. No, don't laugh - there are many
precedents of, for example, the Prolog engine being implemented in C so
that relational databases, symbolic algebra and so on can be done more
effectively. This, to me, represents one extreme of mixed-language
programming and is not advisable as a general rule.


Actually, the only thing I miss when using Gofer is access to the system
clock.


Andrew Bromage.
--


Post a followup to this message

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