October 2001 - Haskell

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

FreeBSD + Graphics
by Korwnios 22 Oct '01

22 Oct '01

Hi everyone, during the weekend I tried unsuccesfully to install the graphics library: (My system: FreeBSD, gmake-3.79.1, hugsFeb2000) # gmake -C graphics-2.0.3/lib/x11 gmake: Entering directory `/root/graphics-2.0.3/lib/x11' cc -I /usr/X11R6/include StdDIS.c -c cc -shared -nostdlib -L /usr/X11R6/lib -lX11 -o StdDIS.so StdDIS.o cc -I /usr/X11R6/include X.c -c cc -shared -nostdlib -L /usr/X11R6/lib -lX11 -o X.so X.o cc -I /usr/X11R6/include Xlib.c -c cc -shared -nostdlib -L /usr/X11R6/lib -lX11 -o Xlib.so Xlib.o rm X.o StdDIS.o Xlib.o gmake: Leaving directory `/root/graphics-2.0.3/lib/x11' -------- # runhugs -Pgraphics-2.0.3/lib/x11: graphics-2.0.3/demos/HelloWorld.hs runhugs: Error occurred Reading file "graphics-2.0.3/demos/HelloWorld.hs": Reading file "graphics-2.0.3/lib/x11/GraphicsUtils.hs": Reading file "graphics-2.0.3/lib/x11/GraphicsCore.hs": Reading file "graphics-2.0.3/lib/x11/GraphicsEvent.hs": Reading file "graphics-2.0.3/lib/x11/GraphicsWindow.hs": Reading file "graphics-2.0.3/lib/x11/Xlib.hs": Reading file "graphics-2.0.3/lib/x11/StdDIS.hs": Reading file "/usr/local/share/hugs/lib/exts/Int.hs": Reading file "/usr/local/share/hugs/lib/exts/Bits.hs": Reading file "/usr/local/share/hugs/lib/exts/Int.hs": Reading file "/usr/local/share/hugs/lib/exts/Word.hs": Reading file "/usr/local/share/hugs/lib/exts/Addr.hs": Reading file "/usr/local/share/hugs/lib/Monad.hs": Reading file "/usr/local/share/hugs/lib/exts/Foreign.hs": Reading file "graphics-2.0.3/lib/x11/StdDIS.hs": Parsing ERROR "graphics-2.0.3/lib/x11/StdDIS.hs": Error loading sym: Undefined symbol "_initModule" # Any Ideas??? TIA. __________________________________________________ Do You Yahoo!? Make a great connection at Yahoo! Personals. http://personals.yahoo.com

1 0

ANNOUNCE: HOpenGL mailing list
by Sven Panne 22 Oct '01

22 Oct '01

HOpenGL has its own mailing list now: http://haskell.org/mailman/listinfo/hopengl Thanks to Simon Marlow for setting it up. HOpenGL is a Haskell binding for the OpenGL graphics API and the portable OpenGL utility toolkit GLUT. It provides easy access to *the* industrial-strength rendering API, available at a wide range of platforms. Apart from GLUT, HOpenGL can be used with a other GUIs, too: MUI, PUI, GTK+ and the native Windows UI, to name a few. The mailing list is intended to discuss HOpenGL API improvements like OpenGL 1.3 extensions or GeForce3-specific stuff, installation troubles, collaboration with the Gtk+HS binding, announcements, etc. Cheers, Sven -- Sven Panne Fon: +49/89/99567000 Fax: +49/89/99567461 BetaResearch GmbH, Betastr. 1, D-85774 Unterfoehring mailto:Sven_Panne@BetaResearch.de http://www.betaresearch.de

1 0