- Haskell - Haskell.org

Re: Enum class
by Jan-Willem Maessen 23 Oct '01

23 Oct '01

Alas, it seems to me Enum is really two classes rather unfortunately lumped together: Correspondence with Int: > class Enum a where > succ, pred :: a -> a > toEnum :: Int -> a > fromEnum :: a -> Int Arithmetic series-like enumeration: > class Enum a where > enumFrom :: a -> [a] -- [n..] > enumFromThen :: a -> a -> [a] -- [n,n'..] > enumFromTo :: a -> a -> [a] -- [n..m] > enumFromThenTo :: a -> a -> a -> [a] -- [n,n'..m] Having recently had to tweak prelude definitions of all of the above, I can personally testify that the situation is not a happy one: We can't meaningfully define correspondence with Int for type Integer, much less Float, Double, etc. The default enumFrom... use toEnum on Int sequences, and as far as I can tell are no use to anyone; Bounded types must close off the ends of the enumeration at minBound and maxBound, and unbounded types won't fit into an Int. So, what's to be done? * In the report, give clear and explicit definitions of enumFrom... for Float and Double. This could be done right now. The toughest part is deciding what the behavior at extremes should be; any behavior is bad, and so picking one with appropriate caveats should be just fine. I don't foresee agreement on which bad behavior is appropriate. Definitions for the methods in the first category might be nice, too. Perhaps they should signal an error. I'm clueless as to whether pred and succ just add/subtract 1 or whether they ought to round as well. * Get rid of the useless (and in truth actively dangerous) default methods for enumFrom... and kin. This could be done now, I think. * Definitions of enumFrom... for Int which deal gracefully with overflow might be a nice addition to the report as people get them wrong. The Feb. 2000 release of hugs, for example: Prelude> [(maxBound::Int)-2..maxBound] [2147483645,2147483646,2147483647,-2147483648,-2147483647,-2147483646,-2147483645, etc... [GHC appears to do it right, I have no idea about current hugs or nhc versions.] * Add definitions for boundedEnumFrom... to the Prelude, or perhaps to a library. This might or might not be a big change for Haskell 98; I forget where Simon PJ's drawn the line. It does reflect reality, though. * Split the Enum class into two. Possibly "correspondence with Int" belongs in "Bounded"---but it depends what you think "Bounded" means. Int64 and Word probably don't fit the model too well. In any case, this can't really be a revision to Haskell 98; it needs to be thought about in future Haskell versions. What say others? Is this sensible? Or have I let my recent frustrations take hold? -Jan-Willem Maessen Eager Haskell Project jmaessen(a)mit.edu

2 1

suggestion
by Andre W B Furtado 23 Oct '01

23 Oct '01

What do you all think about activating the mechanism that automatically includes the name of the list before the subject of a mailing list email? For example: "[hugs-users] Installation problems" or "[haskell] newbie question". I think this would be a nice way to make massages more organized and help people who sign multiple lists. I heard somewhere that this is possible, isn't it Simon? Cheers, -- Andre

5 5

Enum class
by Ch. A. Herrmann 23 Oct '01

23 Oct '01

Hi Haskellers, assuming that the type class "Enum" represents enumeration types, there are two questions for me: (1) What is the justification for the types "Float" and "Double" to be members of the type class "Enum"? This might induce students to use floating point values as counters in arithmetic sequences. (2) Why not make tuples of bounded enumeration types themselves bounded enumeration types? E.g., [(False,False)..(True,True)] could evaluate to [(False,False),(False,True),(True,False),(True,True)] and it is comprehensible since the ordering in the sequence equals the lexicographic ordering imposed on tuple comparison. Cheers Christoph

5 8

Incoherence
by John Hughes 23 Oct '01

23 Oct '01

I noticed today that the presence or absence of a type signature can change the RESULT of an expression in Hugs and GHC nowadays. Here's an example: a = (let x = ?x in x with ?x = 1) with ?x = 2 -- a == 2 b = (let x :: (?x :: Integer) => Integer x = ?x in x with ?x = 1) with ?x = 2 -- b == 1 It's the infamous monomorphism restriction at work, again, of course. Now, what are the proof rules for reasoning about implicit parameters again (:-)? John Hughes

4 3

Re: Scope of imported names
by Wolfgang Lux 23 Oct '01

23 Oct '01

Karl-Filip Faxen wrote > Section 5.5.2 relates to name clashes and has an interesting example > towards the end: > > module F where > > sin :: Float -> Float > sin x = (x::Float) > > f x = Prelude.sin (F.sin x) > > where the type signature refers to the local "sin" rather than the imported > although none of them is visible unqualified. These rules are quite tricky > to understand, I think. They are also different in spirit from the rules The Haskell report seems to be inconsistent here (once again). In the beginning of section 5.3 it says Imported names serve as top level declarations: they scope over the entire body of the module but may be shadowed by local NON-TOP-LEVEL bindings. Thus, the definition of sin in module F is invalid because another top-level declaration of sin already exists due to the (implicit) import of the Prelude. In order to redefine sin locally the imported definition should be hidden and imported only qualified: module F where import Prelude hiding(sin) import qualified Prelude(sin) ... > for instance declarations in section 4.3.2 where the binding occurrences > for the names of the methods must be qualified if the unqualified method > name is not in scope. In the "sin" example it is allowed to resolve the > name clash using the "extra" knowledge that it is illegal to provide type > signatures for imported names, wheras in the case for instance declarations > we may not use the corresponding "extra" knowledge that only methods in > the instance'd class may be bound by the bindings. > > What I'm driving at is this: I propose that top level bindings shadow > imported names and that qualified names can not be used to refer to > declarations in the same module. The second part is going to conflict with the revised report which relies on the qualified names of entities in order to specify which entites exported from module M (module M) where { ... } > /kff > > who feels very relieved at having come out publicly in favour of shadowing > imported names ;-) Wolfgang who prefers to forbid shadowing of imported names :-) -- Wolfgang Lux Phone: +49-251-83-38263 Institut fuer Wirtschaftinformatik FAX: +49-251-83-38259 Universitaet Muenster Email: wlux(a)uni-muenster.de

3 2

rank 2-polymorphism and type checking
by Janis Voigtlaender 23 Oct '01

23 Oct '01

Hello, assume I want to have the following function: > test :: (forall t . (forall a . t a) -> t b) -> b -> b > test g x = g (\f y -> y) id x This should be well-typed if the type constructor t is instantiated as follows: t c = forall d . (c->d) -> d -> d Of course, I don't expect type inference to detect this, so I give explicit annotations: > test :: (forall t . (forall a . t a) -> t b) -> b -> b > test g x = (g :: (forall a . (forall d . (a->d) -> d -> d)) -> (forall e . (b->e) -> e -> e)) > ((\f y -> y) :: (forall a . (forall d . (a->d) -> d -> d))) > (id :: (b -> b)) > (x :: b) GHC 4.08 complains: Couldn't match `forall a d. (a -> d) -> d -> d' against `forall a. t a' Expected type: (forall a d. (a -> d) -> d -> d) -> (b -> e) -> e -> e Inferred type: (forall a. t a) -> t b1 In an expression with a type signature: g :: forall b. (forall a d. (a -> d) -> d -> d) -> forall e. (b -> e) -> e -> e Clearly, giving the annotations was not enough to make the type checker accept the program, since it still tries to perform a higher-order matching. But, how can I make explicit for which type constructor t (namely the one given above) I want to use g (which is polymorphic over t)? I guess, in polymorphic lambda calculus (where types are explicitly abstracted) I should be able to apply a polymorphic g to some concrete type to obtain an instance (does this also work for type constructors?). But, how to do it in Haskell? Note that it doesn't help me to choose another type for "test", because I'm interested in the "free theorem" for exactly the given type of g. Thanks for any hints! Regards, Janis. -- Janis Voigtlaender http://wwwtcs.inf.tu-dresden.de/~voigt/ mailto:voigt@tcs.inf.tu-dresden.de

2 1

Re: Incoherence
by Marcin 'Qrczak' Kowalczyk 23 Oct '01

23 Oct '01

Tue, 23 Oct 2001 08:00:34 -0700, Jeffrey R Lewis <jeff(a)galois.com> pisze: > The best solution is to find a good way to eliminate the DMR. Separating syntaxes of function definition and pattern binding would have the right effect IMHO, but it's a radical change which breaks compatibility and customs. As we are at it, perhaps there should be a way to write strict pattern bindings in let. I recently wrote this: ... some previous cases omitted ... escape (x:xs) = '\\':digit d2:digit d1:digit d0:escape xs where n = ord x (d21, d0) = n `quotRem` 10 (d2, d1) = d21 `quotRem` 10 digit d = chr (ord '0'+d) Laziness is completely unnecessary here, but GHC is not able to optimize it out (even though it has the right to do so; previous cases did evaluate x, and there is no division by zero nor out of range argument of chr). I'm not against lazy 'let' in general. I often write a large bunch of equations in 'where', letting the compiler solve dependencies. Making all tuple unpacking strict would be silly. There is no perfect solution... Adding '$!' or 'seq' here would make it ugly. I would like to seq not just d2,d1,d0 but digits converted to Char, so I would have to introduce three extra variables. In fact I would like to perform the computation which allocates the room for four list cells along with their Char objects in one go, and then computes and spreads all digits without further allocation. Only laziness for the final 'escape xs' is practical in this case. So it's like I want the first three (:) to be strict in both arguments and the last (:) to be strict in the first argument. Can't be written nicely in Haskell. What is the most readable way to eliminate all laziness here except final 'escape xs' in the current Haskell? What would have to be changed in the language to improve it? -- __("< Marcin Kowalczyk * qrczak(a)knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK

1 0

RE: suggestion
by Simon Marlow 23 Oct '01

23 Oct '01

> What do you all think about activating the mechanism that > automatically includes the name of the list before the subject > of a mailing list email? > For example: > "[hugs-users] Installation problems" or "[haskell] newbie > question". I don't like the extra prefixes, but if most folk would prefer them then I can turn them on. Let me know if you have a preference one way or the other (don't mail to the list). Cheers, Simon

2 1

ANNOUNCE: Hat 1.10 and nhc98 1.10
by Malcolm Wallace 22 Oct '01

22 Oct '01

Hat 1.10 and nhc98 1.10 ----------------------- http://www.cs.york.ac.uk/fp/nhc98/ We are pleased to announce a new release 1.10 of Hat (the Haskell Tracing system), and the nhc98 compiler. This is a bugfix release. Its main feature is that the compiler's qualified import/export mechanism has been overhauled to fix some serious shortcomings, and to meet the new revised Haskell'98 specification. We have also taken the opportunity to improve some presentation aspects of the various Hat tracing tools, based on feedback from users. Regards, The Hat team

1 0

Re: Scope of imported names
by Wolfgang Lux 22 Oct '01

22 Oct '01

Hello! > Well, it's not that simple currently. Name clashes are only illegal if they > lead to unresolvable references. Thus if we have Intricate, indeed. I didn't expect to be able to define a function which I cannot reference with its unqualified name. > > > What I'm driving at is this: I propose that top level bindings shadow > > > imported names and that qualified names can not be used to refer to > > > declarations in the same module. > > > > The second part is going to conflict with the revised report which relies > > on the qualified names of entities in order to specify which entities export > ed > > from module M (module M) where { ... } > > That's right (this refers to section 5.2, fifth numbered item). What is > the rationale behind requiring the qualified name to be visible also? If I remember right (I didn't track this down in the mail archives), the reason was to clarify the meaning of an as clause on an import. I.e., the export list of module M(module N) import N as P should be empty, while module M(module P) import N as P exports all of the entities exported from module N. > > who prefers to forbid shadowing of imported names :-) > > Even by nested bindings? No. Otherwise you would probably ask me why I don't want to forbid shadowing of global names by local ones. However, I still don't like the proposal because it allows to shadow imported definitions without noticing. IMHO this is less a problem for local definitions inside a function (which is rarely more than few lines long and thus more easily comprehensible) than for a whole module. Wolfgang -- Wolfgang Lux Phone: +49-251-83-38263 Institut fuer Wirtschaftinformatik FAX: +49-251-83-38259 Universitaet Muenster Email: wlux(a)uni-muenster.de

1 0