Dear Sigbjorn
(This is cc'd to the Haskell list. This message will be long and boring
to anyone not interested in the nuts and bolts of Time.)
Thank you for fixing Time.lhs. But now I've looked at it again
I think it is still inadequate. That's not your fault, it's
because the standard is. Ti
Fergus Henderson wrote:
> A minute is always 60 seconds... except when there is a leap second.
> So I think you need TimeDiffMinutes too. You might as well include
> all of them.
Yes you are right. You need TimeDiffMinutes. But you don't need
TimeDiffDays. The other error in my contribution I
Marcin 'Qrczak' Kowalczyk wrote:
> So you can have a difference of 3 months (whatever it means),
> or 14 days, but you can't have 3 months + 14 days?
3 months means "Add 3 to the month and roll over the day, if necessary".
14 days means "Add 14 to the day, and roll it over if necessary".
The two o
Simon Peyton-Jones wrote:
[snip]
> It's not terrible. But all the types are isomorphic to Int,
> so there'd be a case for making them Ints.
Surely you must be joking, Mr Peyton-Jones? A difference in
days is not at all the same thing as a difference in months.
Allowing a difference in days to be
Peter Hancock wrote:
[snip]
> To improve performance, I thought one can represent line structure. I
> think that the original editor just represented the text by a
> character sequence with a cursor, where \n was among the characters.
> Here one could have a line sequence with a cursor, and a cha
Simon Peyton-Jones wrote:
> One difficulty is that the definition tries not to be Unix-centric.
This is exactly the point I would make. It would however be nice
if there were a separate chapter of the standard for Posix-compliant
OS's (and perhaps also one for Windows) which would document GHC's
Is there any chance that someone could send to me in Germany the head of the
canting Puritan who outlawed punning in Haskell 98? I'm trying to migrate
some code which makes heavy use of punning, and I'm about to yet again
(for literally the thirtieth time) fix yet another (subtly different)
const
If all you want to do is learn to program Haskell, then I think the existing
explanations
of monads suffer too much from history. A few years ago we had (>>) and (>>=), but no
"do"
notation. Afterwards "do" was invented, making everyone's life easier. I suggest that
introductions to Haskell s
Antti-Juhani Kaijanaho wrote:
[snip]
> Indeed. But if you get this far, understanding (>>=) quite trivial
> (assuming you don't have problems with higher-order functions).
Yes, it would be quite trivial. But why bother? You only need (>>=)
if you want to declare your own instance of Monad, whic
Antti-Juhani Kaijanaho wrote:
[snip]
> I had many problems writing programs in the do notation until I understood
> the underlying (>>=). Why? For example, in imperative languages I
> can rewrite
>
> a <- b
> c <- f a
>
> as
>
> c <- f b
>
> In Haskell I can't. Why
Don't add more functions like concatSep to the standard library or prelude. Instead
document
what is there better. I found it far easier to find functions in the Standard ML Basis
library than in the Haskell standard. Here are some suggestions for what could be
done:
(1) document the IO funct
Andy Gill wrote:
[snip]
> I've been playing will possible formats of such documentation.
> Have a look at http://www.cse.ogi.edu/~andy/gooddoc.htm
> for what I'm currently thinking of.
This is very much better than what we have already, but I'll make
the following quibbles anyway:
(1) it should be
For comparison, see
http://www.cs.bell-labs.com/~jhr/sml/basis/pages/list-pair.html
I think this style of documentation is fairly useful, and it doesn't take long to
see if the function you want is there. My only quibble with this format is that it
separates the type of a function from its de
I suppose for consistency you need to allow any number of holes in a tuple, so
(,True,) is an expression of type a -> b -> (a,Bool,b).
One possible problem with this is that it means you can no longer think on a syntactic
level of tuples with more than two elements being equivalent to the obvious
Marcin 'Qrczak' Kowalczyk wrote:
[snip]
> Maybe it's simply not possible to compile Haskell more efficiently?
Maybe not yet. But someday we'll have enough processing power to do
really sophisticated whole-program analysis, including decent region
analysis. A lot of the techniques have already b
Kevin Atkinson wrote:
[snip]
> 1) Support for true ad-hoc overloading.
[snip]
> 2) Support for TRUE OO style programming.
[snip]
> 4) Being able to write
> do a <- getLine
> b <- getLine
> proc a b
> as
> proc getLine getLine
[snip]
AAARRRGGH no. I don't like overloading. For one
Jerome K. Jerome wrote
> George said:
>
> "You know we are on a wrong track altogether. We must not think of the
> things we could do with, but only of the things that we can't do
> without."
("Three Men in a Boat", chapter III)
By all means write new libraries. But this doesn't have to have
"S.D.Mechveliani" wrote:
[snip]
> And why the dense matrix representation is better for Haskell?
> Rather i would expect it is the sparse one.
I really don't think this kind of comparison is going to be very meaningful.
I've written some sparse matrix code in C myself. Since memory is often
as im
Fergus Henderson wrote:
[snip]
> What existing functions for testing IOErrors?
> Apart from the Eq and Show classes, Haskell 98 doesn't define any, AFAIK.
> If you're suggesting that Eq or Show be undefined for IOErrors that
> represent sets of exceptions, then I would have to disagree...
I must b
Fergus Henderson wrote:
[snip]
> SML's exception mechanism essentially forces sequential execution,
> and (I think) causes problems for equational reasoning.
> Haskell's exception mechanism preserves referential transparency
> and gives the compiler more freedom to reorder and/or parallelize code.
Fergus Henderson wrote:
[many interesting things which are snipped]
> There are many common examples where exceptions arise for reasons other
> than I/O, for example integer overflow, division by zero, taking the
> square root of a negative number, head of an empty list, and so forth.
When that ha
Fergus Henderson wrote:
[snip]
> So why limit expressiveness by providing only the former?
Why indeed? You are right. I hadn't realised that
a -> IO (Maybe a)
would still suffer from non-determinism.
(Because if you have
x = error "foo" + _|_
it may cause a return of Nothing or else no
Simon Peyton-Jones wrote:
> One solution is to add
> macros (presumably in a more hygienic form than cpp), but I'm reluctant
> to advocate that, because macros undoubtedly do overlap with functions.
You don't need macros. (For speed purposes inline functions are obviously
better.) All you need a
"Manuel M. T. Chakravarty" wrote:
>
> George Russell <[EMAIL PROTECTED]> wrote,
> This sounds interesting. So you want the branch that is not
> taken to be syntactically correct, but it need not type
> check. How about other semantic constraints (visibility of
&g
Matthias Kilian wrote:
> It doesn't. There's no special treatment of constant conditionals, except
> that clever (or rather a not totally braindamaged) compiler may be
> expected to optimize the unreachable branch away. At least this is what
> several Java books say.
Yes, you seem to be right. N
Perhaps I'm being stupid. (It certainly wouldn't be the first time!)
But what does OO give me that I can't get with existential types
(in datatype definitions) and multiparameter type classes? The latter
seem to me much more powerful, since I can add dancing and singing methods
to objects without
Simon PJ is too valuable to lose. I
(a) second the creation of comp.lang.haskell;
(b) suggest that [EMAIL PROTECTED] should have a policy
(enforced mechanically if necessary) of 1 contribution of length
at most 5 lines (or 350 characters) per user per thread.
Keith Wansbrough wrote:
[snip]
> I disagree. One major reason is the spam problem: a post to a
> newsgroup essentially guarantees putting your name on a spam mailing
> list, and receiving large quantities of Make Money Fast postings.
I normally spam-proof my e-mail address on newsgroups for this
Marcin 'Qrczak' Kowalczyk wrote:
[snip]
> But when Unicode finally comes... How should Haskell's textfile IO
> work?
I don't think the current standard functions for textfile IO would
have too many problems. You can do hSeek in Haskell, but
"The offset is given in terms of 8-bit bytes" (library
It would be nice to be able to say
module Shape(
Shape,
Square :: Int -> Shape,
RotateDegrees :: Int -> Shape -> Shape,
...
) where . . .
Ideally one would want to be able to have instance declarations as well.
This would mean that someone using the Shape module wo
I think the whole idea of making strings lists of characters is barmy, and
one of the few things which are a big disadvantage of Haskell over ML.
The consequence is that one must take a huge performance hit on any portable
code that deals with text a lot (as most code does), for the very dubious
b
Andreas Marth wrote:
>
> I just tried the ghc-4.045 for Win32-sytems and got the error "Variable not in
> scope: 'fromInt' ".
Someone correct me if I'm wrong, but I think the all-purpose function
you are supposed to use to turn an integer into some other sort of
number is called "fromIntegral".
I think the GHC developers have got their priorities about right. Yes, GHC is
slow, hard to build, and big. That's because it's a research project.
It's more important now to concentrate on demonstrating that Haskell is a good
language for all sorts of real programming problems. It won't be
Daan Leijen wrote:
[snip]
> Representing the 'args' as a value in haskell is probably not
> the right thing to do. For one thing, it is not possible to substitute the
> value 'args' with its definition, since it is unknown until load time.
>
> I think that the 'dynamic environment' info is much b
Personally I have only one gripe with the Random class in Standard Haskell;
this is that it provides too much functionality.
In general I think you can only have two of the following 3:
(1) good random numbers
(2) speed
(3) small state
For example the Mersenne Twister is very very good and fast
I might be slightly more inclined to look at Clean if it was free, not just
to people in educational environments.
Matt Harden wrote:
> I don't think that's really true. If I understand it correctly, the
> state can be any type; it doesn't have to fit in, say, an Int or other
> small type. I think the Mersenne Twister could be implemented as an
> instance of Random.RandomGen. The only thing is I don't reall
Sven Panne wrote:
>
> Just a thought: Some compilers for other languages (e.g. Java and
> Eiffel) warn the user about deprecated features, but continue
> compilation. Given the current state of flux in the Haskell libraries,
> this would be a nice thing in Haskell, too. So my suggestion is a new
Chris Angus wrote:
>
> Put simply
>
> What do people think about being able to access functions from other modules
> without
> importing the module.
>
> i.e. Rather than
>
> ---Start-
> import Foo
> -- call f
> callFoof x = f x
> --End
>
> W
(sorry, can't remember the original author)
> | The correct definitions would be:
> |
> | take -2 -- drops the last 2 elements from the list
> | (takes everything except the last 2 elements)
> | drop -2 -- grabs the last 2 elements from the list
> | (drops everything ex
Chris Angus wrote:
> One thing I dont like, is going through IO, although I guess this wouldnt
If you're going to have reflection you might as well have dynamic loading,
in which case you simply have to go through IO, because you're interacting with
previously unchecked bits of the outside world.
Simon Peyton-Jones wrote:
> b) genRange (snd (next g)) = genRange g
>genRange (fst (split g)) = genRange g
>genRange (snd (split g)) = genRange g
I can't see any reason why genRange shouldn't just depend on the type. So why
not just specify that
genRange _|_
is defined?
I think you
Jerzy Karczmarczuk wrote:
> > > class RandomGen g where
> > >next :: g -> (Int, g)
> > >split :: g -> (g, g)
> > >genRange :: g -> (Int, Int)
> > >genRange _ = (minBound, maxBound)
>
> Do you always use integer random numbers?
No. But this is the primitive class we're discussing
(LONG and about floating point, so I suspect many Haskellers are not
going to be interested in this message . . .)
Julian Assange wrote:
>
> The precission and or rounding used by hugs/ghc seems strange, to wit:
>
> Prelude> sin(pi)
> -8.74228e-08
> Prelude> pi
> 3.14159
> sin(3.1415926535897932
Jerzy Karczmarczuk wrote:
> but one should always try to perform all
> the needed reductions before the floating precision gets out of
> control. There are nice recurrences which simplify the computations
> with trigonometric functions. But between 0 and Pi/4 it should be
> well done.
No one shoul
Julian Assange wrote:
> Once you are within a few UDP, the underlaying grainyness of the
> representation is going to get you, so that smoothe, monotonic line
> segment you have below, will look like an appalling zigzag at
> best. This is my point. Near the limits of precession, the error
> introd
George Russell wrote:
>
> Julian Assange wrote:
> > Once you are within a few UDP, the underlaying grainyness of the
> > representation is going to get you, so that smoothe, monotonic line
> > segment you have below, will look like an appalling zigzag at
> > be
Karlsson Kent - keka wrote:
> ?? Let me for a moment assume that I haven't completely
> lost my mind... (which I might have...)
No, I don't think you've lost your mind; indeed I agree with everything you
say.
(ASCII art clipped). I would write that as something like
X
X
X
X
(and
(I've just wrenched this debate from glasgow-haskell-bugs and hugs-bugs to
haskell; I hope no-one minds.)
Marc van Dongen wrote:
>
> George Russell ([EMAIL PROTECTED]) wrote:
>
> : Marc van Dongen wrote:
> : > Wouldn't that make Enum depend on Ord?
> : > Doe
Marc van Dongen wrote:
> I think it has to respect the implicit order which
> is defined by toEnum and fromEnum. But I may be wrong.
Well that's the current definition. But if you have toEnum and fromEnum
that's much stronger than Ord. I don't like toEnum/fromEnum anyway; it makes
no sense for D
"Manuel M. T. Chakravarty" wrote:
> IMHO it would be much more important to think about a
> mechanism for automatically extracting all the interface
> information (including the interface comments) from a
> Haskell module. Something like an automatically generated
> Modula-2 definition module tha
I have no problem with software having an explicit license, I just don't see
that it normally needs to be quoted at the top of EVERY module. (There
are probably exceptional jurisdictions where it does, but not many.)
The GHC method, where the license file is in the distribution and easy
to find
Frank Atanassow wrote:
> What do you all think?
Well I suppose that includes me, but I'm a bit confused. I've looked at some of
the .lhs files containing the source of GHC, but the so-called literate nature
of the code doesn't seem to me to make it any better. Specifically,
it doesn't do anythin
"D. Tweed" wrote:
> Documentation is a vague term: certainly it'd be undesirable for a
> specification to the libraries to just a literate copy of the code
> itself. But if you're thinking in terms of an open source project where
> people fix bugs in the libraries then libraries that contain some
"D. Tweed" wrote:
> * Comments that actually contain meta-program information, eg pragmas
The Haskell standard system for putting information for the compiler in
things which look like comments is obnoxious, but fortunately not _very_
common. I don't think it justifies adding yet another comment
> Karlsson Kent - keka wrote:
>
> Well, that doesn't even look much like XML: it's not well-formed XML.
Personally I'd rather people spent time trying to make their comments clear,
rather than worrying about correctness of XML tags . . .
In any case, in the original example
Html
0.1
Volker Wysk wrote:
>
> Hello.
>
> The mentioned requirements point to using SGML for literate programming.
> This would lead to a systematic approach.
Can you summarise please the main ways in which (as an example) GHC development
would be helped if SGML was used?
Fergus Henderson wrote:
[snip]
> For FLOOR_{F->I}(NaN), the result is defined as a NaN:
[snip]
> But in both cases this doesn't really make much sense to me,
> since here the result type of the operation is an integer rather
> than floating point type. I guess the earlier part of 6.1 does
> shed
One further point I want to make. It should not be the purpose of the
Glasgow Haskell Implementors to solve all the world's programming problems;
they should focus on providing a good set of Haskell tools. As I think this
discussion has illustrated, there are a number of high-tech experimental
l
"Ch. A. Herrmann" wrote:
> I believe that if as much research were spent on Haskell compilation as
> on C compilation, Haskell would outperform C.
I wish I could say I believed that. The big thing you aren't going to be
able to optimise away is laziness, which means you are going to have unev
"Manuel M. T. Chakravarty" wrote:
> Unfortunately, this has exactly the same problem as Modula-2
> has: You have to duplicate types and comments for all
> exported entities, or leave the implementation `naked'. (In
> M-2, you had to repeat the type and people usually did not
> provide comments in
We've had numerous suggestions to add things to Haskell. However in my opinion
many more computer languages (and programs) are ruined by too many features, than
by too few. So here is my own list of things to remove. I realise there is
no chance whatever of it making it into the Haskell stand
"Ronald J. Legere" wrote:
>I dont know how I feel about the specific instances mentioned by
> george, but as a minimalist (or reductionalist, I dont know which) I
> like the idea of at least not adding too much stuff!
> But I do agree about this damn tab business. I have SO MANY TIMES
>
"D. Tweed" wrote:
> The disadvantage of this kind of scheme for haskell
> is that there's no way to get a user setable global variable without
> everything going monadic (or you use an unsafe operation) so it'd have to
> be passed as an explicit argument to every function needing it.
But I bet 99
Sven Panne wrote:
> This
> is such a common pattern that there should be a nicer way to handle
> it apart from the usual unsafePerformIO-plus-noInline-trickery at
> the top level.
If you mean those implicit parameters someone mentioned a while back,
I'm 100% with you. Global variables are BAD in
Malcolm Wallace wrote:
>
> > > class ShowType a where
> > > showType :: a -> String
> >
> > Or you can do what hbc has done for donkey's years and
> > include 'showType' in Show.
>
> Incidentally, nhc98 also has had 'showType' in class Show since the
> year dot - only Hugs and ghc la
Ralf Muschall wrote:
> Where does the habit to use "flip (.)" in many FP people come
> from?
I think it may come partly from category
theorists
Jon Fairbairn wrote:
>
> > Then, the question is why we write
> > result = function operand1 operand2
> > instead of
> > operand1 operand2 function = result
> >
> > I actually think the latter is cooler. :)
>
> I think there may be cultural influences about word order and/
> or writing dire
Why are these illegal? I appreciate that they can't give useful information
to the compiler, which knows the type already from the class, but in my
opinion they are still useful to the maintainer, because they serve as
a reminder of the type.
Mark P Jones wrote:
> I guess that H/Direct would be the best way to take advantage of these
> right now.
I agree actually. Integer only needs to be an implementation of
multiprecision arithmetic; we shouldn't tie it to GMP. There are
other multiprecision arithmetic packages out there, for examp
Marc van Dongen wrote:
> Do you have any data about comparisons with this or
> other packages?
I've just looked around Dave Rusin's page:
http://www.math.niu.edu/~rusin/known-math/index/11YXX.html
but it doesn't seem to contain any up-to-date comparisons; in
particular not of GMP 3. There are
George Russell wrote:
> (GMP is faster if
> you use the mpn_ functions, but then you have to do all your own
> allocation and only get non-negative integers.)
Sorry, I meant GMP is faster if you use mpn_ than if you use the other
GMP functions, not that the mpn_ functions are faster than LIP.
Sebastian Schulz wrote:
>
> Hi folks!
>
> Where can I find math libraries with functions for differential and
> integration calculus, statistics, lin. algebra, ...?
Netlib (the main server seems to be down; here is the UK mirror:
http://www.mirror.ac.uk/packages/prog/num/Netlib.html
If you wa
I know it used to be; see
http://www.haskell.org/mailinglist.html
for example, but the archive I get from that page seems not
to have been updated in two months.
Marcin 'Qrczak' Kowalczyk wrote:
>
> Just a small generic comment:
>
> IMVHO we should concentrate on making the thing useful for programmers.
> Not on exact modelling of mathematical concepts.
I agree completely. There are two problems with freezing large modules into
languages:
(1) they make
I think the way to proceed with basAlgPropos is to implement it
outside the language as a library. (Since it redefines
the basic arithmetic symbols and so on it will be necessary to
tell the user to import Prelude() or qualified and perhaps provide
an alternative version of the Prelude.) The GH
Marcin 'Qrczak' Kowalczyk wrote:
> Show instance for functions should not be needed. It is only for lazy
> programmers who want to make a quick dirty instance, for debugging
> perhaps.
And why not? There is no problem with Showing functions with finite domains.
For example, try:
module ShowFun w
Johannes Waldmann wrote:
>
> Wouldn't it be nice if there were a Haskell compiler backend
> that produced Java bytecode? Then I could write applets
> in my favourite language, compile them, put them on my web page,
> and everyone could execute them in their browser...
>
> Seriously, is there any
For MLj the answers so far as I remember are:
[EMAIL PROTECTED] wrote:
>
> To those of you who are working on implementations:
> How do you implement
>
> 1) tail recursion
You can only do so much. The Java VM has a goto instruction but you
can't jump from one virtual method to another. Things
Is there a standard way of splitting a file name up,
EG (on Unix) "a/b/c" goes to ["a","b","c"]? Knowing the local
file separator would do. I apologise if this is such a standard
function that everyone else but me on the list knows the answer . . .
Peter Hancock wrote:
>
> >>>>> "George" == George Russell <[EMAIL PROTECTED]> writes:
>
> > Is there a standard way of splitting a file name up,
> > EG (on Unix) "a/b/c" goes to ["a","b","c"]?
&g
"Ronald J. Legere" wrote:
>
> SUMMARY: How about a supplement to the standard that contains the
> 'standard' extensions that everyone uses.
One problem I have with this is that "unsafe" operations, being unsafe,
are difficult to fit in with the rest of the language. For example
a common use of
Fergus Henderson wrote:
> (If nothing at all can be guaranteed, then no-one should be using those
> features, and they should be removed from the Hugs/ghc extension libraries.
> But it should be possible to make some guarantees.)
What on earth is a guarantee? GHC is a research project. I don't e
Jon Fairbairn wrote:
> Am I alone in thinking that the prelude is desperately in
> need of restructuring?
No. Personally I think it should be got rid of entirely, or rather
trimmed down to the absolute bare minimum required for the syntax.
By the way I think Sven's proposals are thoroughly exce
Lennart Augustsson wrote:
> By definition, if you follow the standard you can't be wrong. :)
> But the standard can be wrong. Perhaps this is a typo in the report?
I think I looked at this a while back. The standard is kaput. It gets even
worse if you try to make sense of the definitions of suc
Jerzy Karczmarczuk wrote:
[snip]
> I remind you that there is still an uncorrected bug in the domain of
> rationals (at least in Hugs, but I believe that also elsewhere, since
> this is a plain Haskell bug in the Prelude).
>
> succ (3%2)
>
> gives 2%1.
Yes, this is also loony. succ should eithe
Keith Wansbrough wrote:
> GHC is no different from any other compiler for any other language in
> this respect. Floating-point values are *not* the mathematical `real
> numbers', and should not be treated as such. This is second-year CS
> course material.
No, but they ARE, assuming IEEE arithmet
"Wilhelm B. Kloke" wrote:
> IMHO you are not right in this. See W. Kahan on the ridiculous Java
> restriction in FP reproducibility.
We are getting into deep waters here but I think I _am_ right in this case.
Kahan's point (I presume you are referring to his excellent (online)
paper "How JAVA's Fl
Sven Panne wrote:
> (As an aside: I *hate* standards which are not freely
> available, I've never seen a real IEEE-754 document. A $4000 annual
> subscription price for a single person is ridiculous, and I would probably
> have slight problems persuade my company to buy the $40.000 enterprise
> su
Axel Simon wrote:
> One for industrial-strength and
> complete libraries that will remain stable as long as Haskell lives and
> one for the rest.
What you need for that is SUPPORT, for example, to ensure that things
still work when Haskell changes. This is difficult to guarantee in
an academic e
Julian Assange wrote:
> Microsoft VCC once (still?) suffers from this problem. Whether
> it is because it accesses random, unassigned memory locations
> or because the optimiser has time thesholds, is unknown.
Optimisers for Intel can produce different results on floating point
because floating po
Sengan wrote:
> I don't buy this: for a long time the embedded hard realtime people
> refused to use CPUs with cache because they would be
> "non-deterministic".
> They finally gave up, realizing that CPU's with caches are much faster.
> If garbage collection is relatively cheap and makes it 10x f
George Russell wrote:
> (Is there anything better than Baker's train algorithm?)
Sorry, I meant "treadmill" not "train". The train algorithm is an almost-bounded
garbage collection algorithm. (However it fails to be
properly bounded if you have large numbers of in-pointers to a node.)
Sengan wrote:
> > MLKit's regions rather than garbage collection?
>
> Where could I find more info on that?
http://www.it-c.dk/research/mlkit/
Though as someone said, this may not be directly applicable to Haskell,
because lazy application could make things harder.
Tim Sweeney wrote:
> However, a higher-order notion of function application seems sensible in
> many cases. For example, consider the following expressions, which Haskell
> rejects, despite an "obvious" programmer intent:
Casting was done quite extensively by Algol68 (though not of this form).
A
The attached file is accepted by GHC 4.08 and Hugs 98. However if you remove the
declaration of "foo" (and for Hugs, the now unnecessary "where" in the declaration of
class A), both compilers complain. It appears that in the absence of any information,
GHC and Hugs assume that the subject of a c
Zhanyong Wan wrote:
> I guess the rational behind the current design is that everything by
> default should be private. However, I doubt whether it is valid: In
> Haskell the let/where clause allows us to keep auxilliary functions from
> polluting the top-level name space. As a result, I seldom
Why does the Haskell language not allow "type" declarations to appear in
the declaration parts of where and let clauses? I've just been writing a huge
functions which requires lots and lots of repetitive internal type annotations
(to disambiguate some complicated overloading) but I can't abbrev
There are numerous ways of optimising sieving for primes, none of which have much
to do with this list. For example, two suggestions:
(1) for each k modulo 2*3*5*7, if k is divisible by 2/3/5 or 7, ignore, otherwise
sieve separately for this k on higher primes. (Or you might use products of
Alternatively, I wonder whether the current system of type classes is the right
model at all.
Although I prefer the Haskell system, I think it is instructive to compare it
with the Standard ML (SML) system of structures and functors. My point is that
both Haskell and SML impose one of two possib
1 - 100 of 189 matches
Mail list logo
