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 source and
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
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 Unix
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, and parse
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 them
[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-stamps on
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?
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 produces
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,
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
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
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 seem
"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. What
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 them
14 matches
Mail list logo
