John Meacham wrote (snipped):
> I should say that efficiency is the only thing I have been concerned
> about in this conversation.
Well, I think my proposal can be made efficient if you try, using hash tables.
There is a reason why I think top-level <- is inefficient,
because it imposes a single sc
John Meacham wrote (snipped):
> recursive top level declarations are no more tricky than are normal
> recursive lets.
Perhaps I am missing something, but surely one very important problem with
<- at top level is that calling for the value of something defined by <-
causes the corresponding action t
Lennart wrote (snipped):
> An "easy" way to
> prove it is to provide an equivalent implementation that uses only
> pure functions. As far as I remember Control.Monad.ST can be written
> purely. And I think the same is true for Data.Dynamic.
I don't see how it can be, since you can use Data.Dynami
John Meacham wrote:
> Now, my mdo proposal as written would have "hello" outputed exactly once
> at module start up time no matter what, whether x is demanded or not. it
> is equivalant to a program transformation that collects all the top
> level initializers and declarations, puts them all in a m
John Meacham wrote (snipped):
> George Russell's library is precicly an invalid use of unsafePerformIO.
> Internally, it does the invalid unsafePerformIO (newIORef) trick which
> is exactly the problem we are trying to solve. hiding it in a module doesn't
> make it go away.
Why does it matter to yo
Tomasz wrote:
> Without unsafePerformIO Haskell gives me many guarantees for free.
> With unsafePerformIO, they are no longer for free, I have to think, prove,
> etc. When I mistakenly give a pure function interface to an unpure
> "function", it can affect my program in most unexpected places.
I th
Thanks John for the list of things for which you need global variables,
indeed where Haskell already has global variables.
I think their disadvantages are overstated. Glasgow Haskell uses them lots,
as does the Workbench (I reckon about 80 or 100 times), as I suspect do
most large programs that ha
I wrote (snipped):
> 3) It needs no extensions to the Haskell language, and only fairly
> standard hierarchical libraries like Data.IORef.
Lennart Augustsson wrote (snipped):
> It uses unsafePerformIO which is very much an extension to Haskell. :)
Ben Rudiak-Gould wrote (snipped):
> I think by Hask
Thanks to the encouraging post
http://www.haskell.org//pipermail/haskell/2004-November/014748.html
from Benjamin Franksen, I have implemented
my proposal which allows the user to define new global variables without
unsafePerformIO, NOINLINE and other such horrors.
http://www.haskell.org//pipe
> I don't know if HTk is still maintained.
Yes it is! It's time I put some more binary bundles up though.
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
Ben Rudiak-Gould wrote (snipped):
If more than one dictionary is allowed per type, this correspondence
breaks down, and all hell breaks loose as a result. We've already seen
this happen with implicit parameters. In a program with implicit
parameters:
* Beta conversion no longer preserves sem
[EMAIL PROTECTED] wrote (snipped):
The running example includes an ORD class -- which is like the Ord
class but can be parameterized by a comparison function, so to
speak.
This is precisely the problem. Rather than being able to use the existing
functions, you have to haul around an extra discrimi
Keean Schupke wrote:
Do you need a language extension at all? You can certainly
do it with the existing extensions!
data ShowDict a
instance Show (ShowDict a) where
showsPrec _ (ShowDict a) = ...
I don't understand. How does that help you to, for example, use a function
which
requires Show Int
Graham Klyne wrote (snipped):
> I like the principle of parameterizing Show to allow for different encoding
> environments (indeed, I had wondered as I was writing my earlier message if
> the two cases were really sufficient). Indeed, in the application area
> that interests me (Semantic Web) it c
John Peterson wrote (snipped):
> The implementer of these functions has to guarantee that the
> actions do not destroy the commutativity of the CIO monad.
Sorry, but several of my variable initialisation actions involve
things like starting up child processes or rapid exits from the program
if unsu
Chung-chieh Shan wrote (snipped):
> The enabling technique behind our solution is to propagate values
> via types (literally), with the help of polymorphic recursion and
> higher-ranked polymorphism. The technique essentially emulates
> local type-class instance declarations. Configuration parame
What ideas do people have for getting rid of unsafePerformIO?
The most common use of unsafePerformIO, for me at least, is initialisation.
There *surely* must be a better way of doing this, but I haven't really
seen much discussion of the topic. Here is my back-of-the-envelope
suggestion for a new
Andreas wrote:
> The most flexible but safe solution is to simply define the indentation
> as the sequence of indentation characters used. Two consecutive lines
> are indented consistently whenever one indentation is a prefix of the
> other. Hence you may freely mix different indentation characters
Graham Klyne wrote (according to Wolfgang Thaller, snipped):
> I think that compilers should issue a warning when indentation that
> determines the scope of a construct is found to contain tab characters.
In an ideal world, TAB characters would never have been put into ASCII, and
this would be my p
Martin Ewig wrote (snipped)
I think that some visual notations are more readable than text
(but not all). In particular, if you try to teach lambda calculus
or type inference to beginners, visual notations can be extremely
helpful.
For some people, perhaps. I don't have a very good mind for visual
I'm quite happy to have Haskell records remain the way they are.
I've used ML quite a lot, which of course has records without constructors.
But the problem with this is that (1) you get massive error messages;
(2) there isn't a mechanism for filling in empty slots. I don't think you
really gain
Glynn wrote (about my binary library, snipped):
> This is similar to UTF-8; however, UTF-8 is a standard format which
> can be read and written by a variety of other programs.
>
> If we want a mechanism for encoding arbitrary Haskell strings as octet
> lists, and we have a free choice as to the enc
Martin quoted Glynn:
> OTOH, existing implementations (at least GHC and Hugs) currently read
> and write "8-bit binary", i.e. characters 0-255 get read and written
> "as-is" and anything else breaks, and changing that would probably
> break a fair amount of existing code.
The binary library I poste
Keith Wansbrough wrote (snipped)
I think I'm missing something... why is this? Do you only allow one
value of each type? It seems to me that updating k1's value should
not affect k2's.
Perhaps you could explain what "insert" is meant to do, since it doesn't
cite a key value.
Keith Wansbrough wrote (snip)
No, because update should not return a new key, it should update the
value of the same key. In other words,
let (m1,k) = insert empty "A"
m2 = update m1 k "B"
in
lookup m2 k
should give "B", not "A", just like with MRefs.
So what does the function
insert2 val
Keith wrote (snipped)
> But George Russell's implementation relied on looking up something in
> one map with a key obtained from another map. I thought type-safe
> MRefs should disallow this.
However if you disallow lookup up in one map with a key from another,
then Ralf Hinze's solution of puttin
In fact I think these Typesafe MRef's are exactly equivalent
to dynamic types. In other words, if you've got one,
you've got the other. Ralf Hinze has just shown that
if you have dynamic types you can implement Typesafe MRef.
The reverse implementation would be something like
> data Dynamic = FM
Steffen wrote
> I need something like
>
> data Type = TCon String {lmtc::Maybe String} ...
>
> but this does not seem to be possible. Instead
> I have to waste identifiers:
>
> data Type = TCon {senseless::String,lmtc::Maybe String} ...
>
> Why? Are there any formal reasons against the
> above decl
I'm afraid I don't much care for this solution either.
(1) it's not at all clear to me what on earth it's good for. The main reason I
use unsafe casting is because I need a way of storing and retrieving a value
in a storage location which does not know its type. For example, a finite map
which co
Andreas wrote
Well, sorting is a special case of permuting, so my idea was to use the library
routine
List.sortBy :: (a -> a -> Ordering) -> [a] -> [a]
passing it a comparison function which ignores its arguments and simply returns
a random bit when invoked, e.g.
permute = sortBy $ \_ _
Wang Meng wrote
I understand that existentially bound types cannot escape.
For example, say we have
data Foo = forall a. Foo Int a
Then we cannot define a function
extract (Foo i a) = a
However,this limitation makes it extremly difficult to program with local
quantifications.Is there any way to by
Jonathan Coxhead wrote (quoting me, snipped)
Add 1 minute to 23:59:60 31st December 2003. I assume that this is a valid
time
and that it will be a leap second; if not choose some other year.
This is complicated since we have multiple overflows. First stage you get the
invalid time
23:60:60 3
Peter Thiemann wrote:
>
> George> OK, what TimeExts does, I hope, is add the appropriate amount of the
>appropriate
> George> time unit (whatever it is) directly, then rely on the CalendarTime
>conversions to
> George> resolve any overflows. This probably isn't very clear,
> Geo
Peter wrote (snipped)
> As far as I read ISO8601 (which also has a notation for durations)
> this is unspecifed :-) And as far as I read TimeExts.lhs it does some
> sort of rollover. My take would be to specify the behavior for adding
> something like a TimeDiff to a base date in a consistent manne
Magnus wrote (snipped)
> Now, Haskell has a garbage collector, so Haskell must know how many
> pointers there are to all objects in the heap (or?). Then, if a finite map
> for example only has one single pointer to it, then it ought to be all
> right to modify the finite map (or whatever datastruct
Tobias Gedell wrote
> I'm looking for large haskell programs with more than 15000 lines of
> code. Does any of you know where I can find such programs? The programs
> found in the nofib suite are not large enough.
The UniForM workbench is currently almost 8 lines (of which 4500 are
actually H
Simon PJ wrote (snipped)
> Meanwhile, I suspect there's an opportunity for someone (or a small
> group) to suggest a new Time library that really does the business, and
> provide an implementation. If it's sufficiently persuasive, all the
> implementations will adopt it and it can become a de-fact
Gertjan Kamsteeg wrote:
>
> Ok, here is an attempt. I don't have time to explain, but it's not Myer's
> algorithm.
[snip]
Yes thanks. But it doesn't seem dramatically faster, on my test cases, than the
Myers algorithm version I have developed; indeed I think it's slightly slower.
However my Myers
Andrew J Bromage wrote:
>
> G'day all.
>
> On Mon, Nov 25, 2002 at 12:19:10PM +0100, George Russell wrote:
>
> > I have a confession to make. Andrew Bromage's list-based code is
> > much faster than my array-based code. So I think I shall end up
> >
Francis Girard wrote:
>
> You caught my attention.
>
> It would be nice if you write your own version from scratch to make all of us
> profit of this.
I have a confession to make. Andrew Bromage's list-based code is much faster than my
array-based code. So I think I shall end up adapting Andrew
Yoann Padioleau wrote:
>
> there is the perl version of the diff algorithm on CPAN that may be
> a better starting point than the C version.
I think in fact I'm going to give up on stealing other people's code and write my
own version from Myer's paper.
George
___
Yoann Padioleau wrote:
>
> George Russell <[EMAIL PROTECTED]> writes:
>
> >
> > This is a well-known problem. The most helpful Web page I could find about it is
>here:
> >
> >http://apinkin.net/space/DifferenceEngine
> >
> > There is a
Since various people seem to have misunderstood the problem, I shall try to state it
more precisely.
What is required is a function
diff :: Ord a -> [a] -> [a] -> [DiffElement a]
for the type
data DiffElement a =
InBoth a
| InFirst a
| InSecond a
such that given
gument. However it doesn't have
to return
the shortest possible output list; it may be that it can compute one which is close to
optimal
much faster. Also if you'd rather have a hash function than Ord I can manage that.
Thanks if anyone can help, and save me a bi
The TimeExts library probably does most of what you want. I really ought to Haddockify
the comments some time . . .
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
Ketil Z Malde wrote:
>
> George Russell <[EMAIL PROTECTED]> writes:
>
> > The situation with Enum on Ratio is pretty bad but at least
> > it's not hopeless, since rational numbers are at least exact. But
> > for Float/Double it seems to be a total disaste
The situation with Enum on Ratio is pretty bad but at least
it's not hopeless, since rational numbers are at least exact. But
for Float/Double it seems to be a total disaster area. Since it seems
to be impossible to abolish Enum Float/Double altogether, would it
at least be possible to make it ra
Ketil Z Malde wrote:
>
> George Russell <[EMAIL PROTECTED]> writes:
>
> > "Ketil Z. Malde" wrote:
> > [snip]
>
> >>> and on Solaris the default representation of a characters is as a
> >>> signed quantity.
>
> >> Why
"Ketil Z. Malde" wrote:
[snip]
>
> > and on Solaris the default representation of a characters is as a
> > signed quantity.
>
> Why should we care?
[snip]
If you want to talk to any C libraries or C programs which use characters, which some
of us do. GNU readline and regex come to mind.
__
"Ketil Z. Malde" wrote:
>
> George Russell <[EMAIL PROTECTED]> writes:
>
> > Ketil wrote (quoting Ken)
>
> >>> On most machines, Char will be a wrapper around Word8. (This
> >>> contradicts the present language standard.)
>
> &
Ketil wrote (quoting Ken)
[snip]
> > On most machines, Char will be a wrapper around Word8. (This
> > contradicts the present language standard.)
>
> Can you point out any machine where this is not the case? One with a
> Haskell implementation, or likely to have one in the future
[snip]
That's
Ashley wrote
[quote]No, a file is always a list of octets. Nothing else (ignoring metadata,
forks etc.).
[/quote]
On MVS at least a file is a list of list of octets, because record boundaries are
not handled by a "record boundary character" but by other means. There are
still more horrible detai
Andrew Bromage wrote
> On Mon, Jul 29, 2002 at 02:50:55PM -0700, Hal Daume III wrote:
>
> > I need a data structure which is a map from Ints to Doubles; the
> > distribution of the Ints is in the range say 0-2 and a map will
> > contain somewhere around 100-200 elements. I need to be able to
Jon Fairbairn wrote
[snip]
> Well, there's two things to consider: Haskell 98, which
> probably shouldn't change, and extended Haskell, which
> probably should. Especially if we can make the rules both
> simpler and better.
[snip]
How can I resist? I proposed the following revised layout rule som
I like layout but I think the existing rules are too complicated. Unfortunately it's
difficult to do anything with them without breaking vast swathes of existing code,
so we'll just have to put up with them.
The reason I think layout is better than using {'s and ,'s is that humans
use the layout
"S.M.Kahrs" wrote:
[snip]
> I don't think this really solves the problem with the left unit
> (not in general, and not for IO either),
> it merely pushes it to a different place.
[snip]
Not being a category theorist I find this all a bit confusing. Can you
give an example where with GHC and the f
Dylan Thurston wrote:
[snip]
> I've often been bothered by the inconsistent treatment of laws in the
> report; why are there laws for functors, monads, and quot/rem and
> div/mod, and not much else? I'm pleased to see that the laws that are
> given actually do have exceptions.
[snip]
Even the quo
Simon Marlow wrote
[snip]
> So the IO monad in Haskell, at least as we understand it, doesn't
> satisfy the monad laws (or, depending on your point of view, seq breaks
> the monad laws).
[snip]
Cheers Simon. One of the awkward things about the Haskell events I implemented
is that although I make
Dean Herrington wrote
> It seems to me that the behavior for `(fromInteger x)::Int`, where x is
> an Integer outside Int range, should be the same (in terms of the
> Haskell report) as that for `y + y`, where y is an Int such that
> `toInteger y + toInteger y` is outside Int range.
I agree almost
I too am against broadening the scope of n+k patterns, for reasons that others have
already
given. In particular, I am absolutely against allowing n+k patterns to be used for
Float/Double.
If n+k patterns are to be meaningful at all, you want matching y against x+1, you want
a unique
x such th
One thing I would very much like to see done in a functional language is fault-tree
analysis.
A fault tree has as nodes various undesirable events, with as top node some disaster
(for example,
nuclear reactor meltdown) and as leaves various faults which can occur, with their
probabilities
(va
I've reconsidered my earlier position and think now that the Prelude is wrong to make
gcd 0 0 an error, and should return 0. It probably doesn't make much difference to
anyone, but it's like 1 not being a prime; it may be slightly harder to explain, but it
makes the maths come out nicer and is i
S.D.Mechveliani wrote
> Does the Report specify that gcd 0 0 is not defined?
Yes. The Report definition says
gcd :: (Integral a) => a -> a -> a
gcd 0 0 = error "Prelude.gcd: gcd 0 0 is undefined"
gcd x y =
The University where I did my Maths degree also had an extremely good Computer Science
department, but sadly this connection was not exploited nearly as much as it should
have been. I have two anecdotes which might be relevant:
(1) I remember being told off by one teaching assistant for writing a
ort, if some other people will do so too so we can debug
the whole thing. Then perhaps we might be able to get the whole thing done by
Christmas.
George Russell
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
Ketil Malde wrote:
>
> George Russell <[EMAIL PROTECTED]> writes:
>
> > In addition, I suggest that, since it is widely agreed that the instances of
> > Enum for Float and Double
>
> And (Ratio a)?
Yes, you've got a point there. They'd none of '
I sent a report to SPJ on Tuesday complaining about the Haskell 98 definition of asin
on Complex. Whatever the outcome of this report, I think the Haskell 98 definitions
for
Complex need the following documentational change. We should document, not in Haskell
code,
but in words, what each fun
Simon Peyton Jones suggested the following changes:
> 1. Move specification of enumFrom and friends from 3.10 to 6.3.4
>
> 2. Specify that for bounded types, (succ maxBound) and (pred minBound)
> are errors.
>
> 3. Specify that succ and pred on numeric types just add/subtract 1
> (subject to
>
I personally think the inclusion of Float and Double in Enum is an unmitigated
disaster.
Enum consists of three separate parts:
(1) succ & pred. These appear for float to correspond to adding or subtracting
1.0. (I am finding this out by testing with ghci; it's not specified where
I wrote
> I'm afraid that I have very little faith in the numerical analysis
> expertise of the typical Haskell implementor, so I think it is dangerous
> to give them an incorrect "default" implementation. I am reminded of
> the notorious ASCII C (very)-pseudo-random number generator . . .
Dylan
Dylan Thurston wrote:
[snip]
> > No. As has been pointed out, this is a bad idea numerically because
> > it will give the wrong answer for sinh x for very small values of
> > x. As a matter of fact, you will also get the wrong answer for very large
> > values of x, where exp(x) can overflow even
Simon PJ wrote:
> Fpr the Revised Haskell 98 report, Russell O'Connor suggests:
> =20
> | Also, I understand you are reluctant to make library changes,=20
> | but sinh and cosh can easily be defined in terms of exp
> |=20
> | sinh x =3D (exp(x) - exp(-x))/2
> | cosh x =3D (exp(x) + e
Alistair David Reid wrote:
> "Rijk-Jan van Haaften" <[EMAIL PROTECTED]>:
> >> What does the language definition say about [tabs]?
>
> Sigbjorn:
> > Nothing at all, I believe, but the convention is [...]
>
> The Haskell 1.4 report says what is meant to happen (section 1.5)
> (which was to follow
Well, I think we all know the answer to this one, namely
{-# NOINLINE [name] #-}
This is, after all, what GHC does, and what several of the
files in ghc/fptools do.
Only slight problem is that according to the Haskell 98
report, including Simon Peyton Jones' revised draft, you
should use:
Alastair David Reid wrote:
>
> > I find it therefore of concern that many crucial Haskell documents,
> > including the standard and, for example, the various Glasgow Haskell
> > manuals, are only available online.
>
> My printed copy of the Haskell 98 report is numbered:
>
> YaleU/DCS/RR-1106
I don't want to seem incredibly Luddite, but there are some things the World Wide
Web is not good at, and one of them is permanence. Try for example finding out
about Glasgow Haskell from http://www.dcs.gla.ac.uk, which was I think the
standard URL a few years ago. In 2050 we may not even have a
The MLj compiler from ML to the Java Virtual Machine (which is being
actively worked on by the geniuses at Microsoft as we speak) expands
out all polymorphism. I helped develop this compiler and I believe
this approach to be a good one. There are particular reasons why it's
good for this case
I hope nobody actually uses this random number generator. It appears
to be linear congruential with period less than 14. The author
of these benchmarks seem to have got this algorithm from "Numerical
Recipes", whose code (at least, in the early editions)
has come in for some very heavy criti
I know it's complete heresy to say so, but I use laziness very
little in Haskell, while I probably pay quite a lot for it
in CPU time and memory, because of all those thunks which have to be
stored. However I prefer Haskell's type classes, syntax and
purity to, say, Standard ML. So I wonder whet
Marcin 'Qrczak' Kowalczyk wrote:
[snip]
> It would require to keep bodies of all polymorphic functions in
> a form allowing instantiation in different modules. For example
> ghc already requires too much memory (even a hundred MB for large
> modules), and it leads to code bloat, so in the current
Andreas Rossberg wrote:
>
> George Russell wrote:
> >
> > I'm sorry if this is a FAQ, but I'm curious to know why Haskell (or at least, GHC
>and Hugs)
> > doesn't seem able to use contexts on variables at the front of data declarations.
>
> Th
Andreas Rossberg wrote:
[snip]
> Such monomorphisation is not possible for Haskell in general, because it
> allows polymorphic recursion. As a consequence, the number of
> dictionaries constructed for a given program also is potentially
> infinite.
[snip]
Yes OK, that's another case, like dynamica
I'm sorry if this is a FAQ, but I'm curious to know why Haskell (or at least, GHC and
Hugs)
doesn't seem able to use contexts on variables at the front of data declarations. For
example the following
data Eq x => Foo x = Foo x
equal :: Foo x -> Foo x -> Bool
equal (Foo x1) (Foo x2) =
I am finding functional dependencies confusing. (I suspect I am not alone.)
Should the following code work?
class HasConverter a b | a -> b where
convert :: a -> b
instance (HasConverter a b,Show b) => Show a where
show value = show (convert value)
___
Sebastien Carlier wrote:
>
> > import Monad
> > ...
> > do y <- liftM unzip m1
>
> Thanks.
>
> I'm constantly amazed by the number of tricks one has
> to know before he can write concise code using the
> do-notation (among other things, I used to write
> "x <- return $ m" instead of "let x
Paul Hudak wrote:
[snip]
> So I suppose the main thing that John and I should think about is
> changing the title. Something like "An Introduction to Haskell for
> People Who Have Previously Programmed in Scheme or Some Other Functional
> Language" might be good! :-)
"A Gentle Introduction to Has
Simon Peyton-Jones wrote:
>
> It's a bug in the defn of 'partition' in the Haskell 98 report.
> I have (still) failed to publish this as an errata, let alone revise
> the report itself, so the buggy defn stands at present, I'm afraid.
>
> I really plan to get to the revision in early '01.
One th
Paul Hudak wrote:
>
> > Unforunately, the "Gentle Introduction To Haskell" that
> > haskell.org links to is not a very useful introduction.
>
> John and I should probably rename this document, since it really isn't a
> very gentle intro at all. We should probably also downplay it's
> prominance
I think the following program
import List
main = putStr . show . fst . (partition id) . cycle $ [True,False]
should display [True,True,True,...]. But instead, for both GHC and Hugs,
you get a stack overflow. Is this a bug, or could someone explain it to me?
___
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
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
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
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
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
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
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.
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:
> 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
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
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
1 - 100 of 189 matches
Mail list logo
