Craig Dickson wrote:
> Jeff Dalton <[EMAIL PROTECTED]> wrote:
>
> > Sure, cat in itself isn't very interesting. But cat is just a simple
> > case of a more interesting problem, that of writing what Unix calls
> > "filters": programs that take some input from a file or pipe or other
> > similar
Craig Dickson wrote:
> I would think that if one wishes to learn functional programming, one would
> be best advised to start out solving problems that are well-suited to the
> functional paradigm -- where most of the solution involves manipulating the
> data in memory, rather than getting the da
> Sure, cat in itself isn't very interesting. But cat is just a simple
> case of a more interesting problem, that of writing what Unix calls
> "filters": programs that take some input from a file or pipe or other
> similar source and transform it into some output.
.. and if standard Un
Jeff Dalton <[EMAIL PROTECTED]> wrote:
> Sure, cat in itself isn't very interesting. But cat is just a simple
> case of a more interesting problem, that of writing what Unix calls
> "filters": programs that take some input from a file or pipe or other
> similar source and transform it into some
On Fri, 11 Jun 1999, Malcolm Wallace wrote:
> Well, compiler-independent is possible (e.g. hmake extracts
> dependencies from any Haskell sources, regardless of compiler.)
> However, language-independent is much more difficult. How could one
> tool deal with all of C, C++, Haskell, and LaTeX? S
David Tweed writes:
> > $ gcc -M main.c >>Makefile
> > $ ghc -M Main.hs >>Makefile
> > $ hmake -M MyProg >>Makefile
>
> Since several people have pointed out the -M option for gcc I'd better
> explain that, for reasons of no interest to Haskell users, when tackling
> _C++_ it pro
[drifting off-topic]
On Fri, 11 Jun 1999, Malcolm Wallace wrote:
> David Tweed writes:
>
> > I think it'd probably better software engineering to split the two tasks.
> > Other than a rather nasty syntax, make does what it sets out to do quite
> > well: using specified dependencies and time-st
On Thu, 10 Jun 1999, Craig Dickson wrote:
> programming, especially lazy functional programming. If it seems desireable
> to re-implement a standard Unix utility in Haskell, I suggest 'make'. One
> could even design and implement a 'make' that would know all about Haskell
> modules, and parse th
On 10-Jun-1999, D. Tweed <[EMAIL PROTECTED]> wrote:
> On Thu, 10 Jun 1999, Craig Dickson wrote:
>
> > If it seems desireable
> > to re-implement a standard Unix utility in Haskell, I suggest 'make'. One
> > could even design and implement a 'make' that would know all about Haskell
> > modules, an
On Thu, 10 Jun 1999, Craig Dickson wrote:
> programming, especially lazy functional programming. If it seems desireable
> to re-implement a standard Unix utility in Haskell, I suggest 'make'. One
> could even design and implement a 'make' that would know all about Haskell
> modules, and parse the
Sure, cat in itself isn't very interesting. But cat is just a simple
case of a more interesting problem, that of writing what Unix calls
"filters": programs that take some input from a file or pipe or other
similar source and transform it into some output.
It seems to me that functional language
There is a law obeyed by newsgroups, which seems to be
respected here: the most trivial problem, when presented in
a provocative sauce focuses the attention of so many people,
that the issue becomes disturbing.
Lars Lundgren continues to save the soul of Friedrich Dominicus:
FD> I disagree, sm
"D. Tweed" wrote:
>
> I think it'd probably better software engineering to split the two tasks.
> Other than a rather nasty syntax, make does what it sets out to do quite
> well: using specified dependencies and time-stamps on files to run
> `compilation-type' processes in an appropriate way. W
On Thu, 10 Jun 1999, Jerzy Karczmarczuk wrote:
> There is a law obeyed by newsgroups, which seems to be
> respected here: the most trivial problem, when presented in
> a provocative sauce focuses the attention of so many people,
> that the issue becomes disturbing.
>
Several problems
Jerzy Karczmarczuk <[EMAIL PROTECTED]> wrote:
> More seriously, I jumped into this FP paradise from a good, Fortran
> loving milieu, when I found that there were problems very awkward to
> solve using imperative programming. I wouldn't have started to use FP
> just to test that it is possible to
15 matches
Mail list logo
