I applaud the intention of the Haskerl group to make the use of Haskell
easier and, in the same spirit, I would like to suggest some further
extensions to make "literate" programming easier.
Most Haskell users (and certainly all Haskell compiler writers) also
use LaTeX, so I suggest that literat
David M. Goblirsch ([EMAIL PROTECTED]) writes:
Can anyone give me an example---or a reference to an example---which
shows that functional languages are "bad at I/O"? And why is Haskell
perceived to be inadequate for "get-the-job-done" tasks?
Yes, Certainly. Here at York
I know it's late in the day for most of you (or already tomorrow),
but a colleague of mine here at Los Alamos has made a suggestion
I just have to pass along:
Will Partain writes
|We might then match against a list of Foos (type "[Foo]") as follows:
|
|case expr of
| /^{Foo1 _ {4}}({Foo
I would like to congratulate Mr. Partain on this visionary proposal.
The time is right for such a language. I was particularly excited by
the FWIM syntax but I would like to go even further and suggest that
we consider including support for dc syntax[1]. This often-neglected
language represents
David Wakeling writes
|Yes, Certainly. Here at York we have a small electrical hoist in one of the
|Departmental stairwells which is used for lifting expensive and delicate
|equipment onto the upper floor of the building. As part of an experiment in
|real time functional programming, I wrote a Ha
>Paul Hudak writes:
>For every bad story there is a good one.
For every bad story there are two good ones. Recently, a local
hospital suffered many malpractice suits due to faulty software in
their X-Ray machine. So, they decided to rewrite the code in Haskell
for more reliability.
M
David Wakeling writes:
Yes, Certainly. Here at York we have a small electrical hoist in one of the
Departmental stairwells which is used for lifting expensive and delicate
equipment onto the upper floor of the building. As part of an experiment in
real time functional programming, I
For every bad story there is a good one. Recently Haskell was used
in an experiment here at Yale in the Medical School. It was used to
replace a C program that controlled a heart-lung machine. In the six
months that it was in operation, the hospital estimates that probably
a dozen lives were s
Non-strict, purely-functional languages, such as Haskell [1], are
perceived to be inadequate for everyday, get-the-job-done tasks; in
particular, they are seen to be "bad at I/O". Consequently, an
informal working group has been designing an extended variant of
Haskell to address these requirem
|>Paul Hudak writes:
|>For every bad story there is a good one.
|
|For every bad story there are two good ones. Recently, a local
|hospital suffered many malpractice suits due to faulty software in
|their X-Ray machine. So, they decided to rewrite the code in Haskell
|for more reliabili
Paul Hudak writes:
For every bad story there is a good one. Recently Haskell was used
in an experiment here at Yale in the Medical School. It was used to
replace a C program that controlled a heart-lung machine. In the six
months that it was in operation, the hospital estimates that prob
Non-strict, purely-functional languages, such as Haskell [1], are
perceived to be inadequate for everyday, get-the-job-done tasks; in
particular, they are seen to be "bad at I/O". Consequently, an
informal working group has been designing an extended variant of
Haskell to address
| Lennart Augustsson (Chalmers) writes, "I haven't started adding
| Haskerl to LML/HBC, but it shouldn't take long. By FPCA definitely."
As Lennart was heard decrying excessive monadery as recently as September,
I'm pleased to hear he's gotten on the bandwagon. That he's given himself
over two
13 matches
Mail list logo
