John Hughes wrote:
> We can construct rather large polymorphic values, which have
> to be converted in linear time to the same value of a
> different type.
>
>
> All true, but I doubt whether any of this is a big deal. MLers already live
> with their "value restriction", w
George Russel proposed a search for things which should be deprecated.
I have a very distinct unfondness for contexts in algebraic data type
declarations. They make absolutely no difference except move type
errors to a different part of a program (or rather, they
John Hughes wrote:
| `x := []' wouldn't be problematic, just monomorphic.
| That is, x must be used consistently as a list of a
| particular type.
Just to check if I understand you correctly. In your
proposal, does the following thing share `x
I was very surprised when I discovered (writing a bit more complicated
program) that a program like
> import Numeric ( floatToDigits )
> print $ showFFloat Nothing 0.01 ""
enters in to infinite loop. I found that (formatRealFloat FFFixed
Nothing) do not like displaying numbers less than 0.1.
For
Thu, 25 Oct 2001 09:47:31 +, Levent Erkok <[EMAIL PROTECTED]> pisze:
> Another place where `:=' bindings are badly needed is the recursive
> do-notation (mdo, as supported in hugs.) In an mdo, let bindings
> have to be monomorphic, because they are passed back to the mfix
> loop in a lambda b
On Thu, Oct 25, 2001 at 09:47:31AM +, Levent Erkok wrote:
> Another place where `:=' bindings are badly needed is the recursive
> do-notation (mdo, as supported in hugs.) In an mdo, let bindings have
> to be monomorphic, because they are passed back to the mfix loop in a
> lambda binding. Henc
On Thursday 25 October 2001 07:21 am, John Hughes wrote:
> My proposal is that := should bind *monomorphically* -- just like lambda
> binding. The motivation for that is that a polymorphic function can easily
> become overloaded after a small change to the program, such as adding
> removal of dupl
There's a nice article on HaXml (Runciman and Wallace's
excellent Haskell toolkit for XML) in the "XML Matters"
section in IBM developerWorks. From the abstract:
| XML Matters : Transcending the limits of DOM, SAX, and XSLT
| ---
| Consider H
Simon Peyton-Jones wrote:
[snip]
>
> The Revised Haskell 98 report is suppposed to be in
> conclusion mode. An attempt to decide what features are
> deprecated would open up a big new debate. One could
> instead list features which are controversial --- that would
> be easier. Whether it would
After lots of unsuccessful searching and trying:
Does anyone know how to run Fran with the newest
version of ghc?
-Tobi
--
GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haske
| Somebody raised the issue why to/fromEnum doesn't use Integer
| instead of Int. This would, it would seem, solve at least
| some of the Enum problems that arise from (integral) types
| with more than 4G values. So, again, why not?
There was an extended discussion on this point, I believe,
| In addition, I suggest that, since it is widely agreed that
| the instances of Enum for Float and Double are highly
| unsatisfactory, the report should give these instances the
| same status as n+k patterns have (in 1.4 of the recent
| revision). In particular, their use should be "discoura
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 'em be missed.
Of course mathematicians are well
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)?
>are highly unsatisfactory
-kzm
--
If I haven't seen further, it is by standing in the footprints of
Hi!
The binding form := must absolutely have a completely monomorphic type.
A while back I posted the result that the MR kills principal types in
Haskell. The problem with the MR is exactly that it introduces types
which may be polymorphic but not overloaded. So if we want to regain
principal typ
Hi!
George Russel proposed a search for things which should be deprecated.
I have a very distinct unfondness for contexts in algebraic data type
declarations. They make absolutely no difference except move type
errors to a different part of a program (or rather, they add type
errors). In that se
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 want to trim the headers, but don't know the history of this
thread. Also cc:ed back to the Haskell list.)
On Thu, Oct 25, 2001 at 11:11:42AM +0200, Ketil Malde wrote:
> Dylan Thurston <[EMAIL PROTECTED]> writes:
> > I agree that Enum instances for Float/Double are not likely to be
> > useful
Malcolm Wallace <[EMAIL PROTECTED]> writes:
>> 5. In Appendix A, the Enum class defn, add comments to explain that the
>> default methods only work for types whose fromEnum/toEnum range fits
>> inside Int.
> I would rather have correct default definitions.
Somebody raised the issue why to/from
Hello, and thanks for the various answers!
Martin Odersky writes:
>
> Simon,
>
> You are correct to have doubts. Indeed our system would not handle
> this case, as type variables can only be instantiated to monomorophic
> types, not to type schemes. The closest you can get to it is to wrap
> the
John Hughes wrote:
| `x := []' wouldn't be problematic, just monomorphic.
| That is, x must be used consistently as a list of a
| particular type.
Just to check if I understand you correctly. In your
proposal, does the following thing share `x'?
let x = fac 100 in x + x
(My understanding
22 matches
Mail list logo
