Jerzy Karczmarczuk writes:
Steven Bevan wrote interesting numeric routines a long time ago.
Actually I did little more than transliterate the algorithm
descriptions I found in a book on numerical analysis. I know next to
nothing about numerical analysis so I have no idea if they are
Everyone now acknowledges that Haskell's modules are the weakest part
of the language, and people are working on ways to fix that (yes,
someday I hope there will be a Haskell 2).
Are any details available as to what directions this work is taking?
I'm aware of of some work to extend
When I was dabbling with some numerical analysis code a while ago I
noticed what appears to be an overspecification in the way "bounds"
interacts with list comprehensions. Sometimes it was important that
the bounds be produced in order and this is the behaviour defined in
the manual (1.1
At the risk of opening old wounds: why weren't ML/FX style modules
included in Haskell? I can think of a number of possible reasons, but
I'm interested in the "official" reason for leaving out such an
important feature.
bevan
On Fri, 18 Dec 92 15:42:42 GMT, kh [EMAIL PROTECTED] said:
On Thu, 03 Dec 92 08:13:17 +, Simon L Peyton Jones [EMAIL PROTECTED]
said:
Simon Why do you need to drop the (..) when it turns into a "data" decl?
Simon You only need do so if you want it to be abstract!
Simon But "type"
Is it possible to import a type and the derived "show" function for it
without having to import all the type's constuctors? For example, in
the following I attempt to import just Lexeme into Token as the
internal details of Lexeme should not be known to Token :-
module Lexeme where
data Lexeme
I wrote:
In article [EMAIL PROTECTED]
[EMAIL PROTECTED] writes:
Isn't the type signature you give incorrect? The parammeters
m and n must have type a (where (a,a) is the index types of
the arrays).
I think your right, but as I can't seem to get to
Now that I've said my piece about syntax, we can get down to some
nitty gritty details of the language ...
The following are two different ways of factoring the L and U sections
needed in Crout reduction. The first version is a direct translation
of some FORTRANish pseudo-code and the second
Well after complaining publically that people spend too much time
worrying about concrete syntax; I'm now going to do just that :-)
I've recently "discovered" arrays in Haskell and in writing a program
or two wrote something like :-
f x!i
I assumed that this would apply _f_ to the _i_th
In article [EMAIL PROTECTED] [EMAIL PROTECTED]
(Paul Hudak) writes:
Array notation conventions aside, I think the simple rule that normal
application has higher precedence than infix application is a Big Win.
So do I, and therefore I'm not seriously suggesting a change.
Howerver,
dependent dumpable ASTs in the
compilers currently being developed?
Stephen J. Bevan[EMAIL PROTECTED]
form of
alternative/extended tags system?
ta
Stephen J. Bevan[EMAIL PROTECTED]
PS the "d" in "kludge" is deliberate, the hacker's dictionary isn't
right about everything :-)
12 matches
Mail list logo
