- Haskell - Haskell.org

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

Scope of imported names
by Karl-Filip Faxen 22 Oct '01

22 Oct '01

Hi all! I have been thinking about the scoping issues for imported names. Of course, this musing is ispired by the formal static semantics I have been working on, but it is also prompted by the revised Haskell report. 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 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. So. Now I've said it. It feels much better now. The first part is, as far as I can see, a compatible change. All programs will mean the same things as before but some additional programs will be legal. Of course, using qualified names to refer to top level declarations now becomes a redundant feature, and I would very much like it removed from the language, but this second change breaks programs. Maybe that is not acceptable for this revision and clarification. Or maybe it is? There is actually a mechanical translation from the old rules to the new: If the module name is M, then some occurences of qualified names of the form M.name, where "name" may be a name of a type, constructor, class or variable (including method or field name) refer to top level declarations in M itself. Call these "local qualified names". Now do the following: 1. For each occurrence of a local qualified name M.f such that "f" is also visible and refers to a different binding (which must be a nested binding), rename that binding (ie alpha convert it). 2. Replace any local qualified name M.name with name. So as far as incompatible changes go, this one is rather benign, I think. I think that accidental name clashes with imported names are annoying, but there are more formal reasons for that change. Consider the definition below, occurring in module M: f = ... M.f ... Is it recursive? That depends on whether it is top level or nested. It might also be illegal if there is an import declaration like import Foo as M (f) in the module, in which case there is a name clash between the imported M.f and the local one. This means that nested declarations have different semantics than top level declarations, which is unfortunate, or that the semantics of bindings such as these can only be given after renaming the module. Cheers, /kff who feels very relieved at having come out publicly in favour of shadowing imported names ;-)

1 0

Lazy Sound File IO
by Carl McTague 22 Oct '01

22 Oct '01

How hard would it be to write a lazy sound file IO module, if only one that dumps a [Int] or [Float] raw to disk sine header? Can anyone help point me in the right direction? Thanks, Carl

1 0

Re: the Haskell Wiki losing pages again
by John Heron 21 Oct '01

21 Oct '01

Hi Shae, All, As you may know the haskell wiki (http://haskell.org/wiki/wiki) occasionally loses pages. This is due to RCS locks not being properly cleared, probably when one of the scripts bombs. However, I haven't been able to track down the exact cause despite sporadic hacking. I have however downloaded and installed a newer version of the software which hopefully will fix the problem. I am just a bit nervous about the upgrade mostly because the user community for pywiki is pretty small. If you feel so inclined, I'd very very much appreciate it if you'd try out my test upgrade at http://haskell.org/newwiki/wiki before I copy the new code over to the production wiki and give me some feedback. I'll copy over the code to the production wiki after I've gotten some indication that it's likely to function at least as correctly as the current install. BTW, I've looked at moving to another wiki such as moin-moin, but that would require translating to the new format or reentering the content. I don't have time for either job, so for now I've decided to just stick to the upgrade. If someone would like to volunteer for a change to a replacement, I'd be glad to assist at least in a small way. If not, that's OK too, I have no big problem with the status quo. Best Regards, John Heron Shae Erisson wrote: > Hello again, > The Haskell Wiki is losing pages again, could you repair it? > much thanks, > Shae Erisson - shae(a)webwitches.com

1 0

strong typing?
by S.D.Mechveliani 20 Oct '01

20 Oct '01

People write Fergus Henderson: H> [...] H> The whole idea of letting you omit method definitions for methods with H> no default and having calls to such methods be run-time errors is IMHO H> exceedingly odd in a supposedly strongly typed language, and IMHO ought H> to be reconsidered in the next major revision of Haskell. Jon.Fairbairn(a)cl.cam.ac.uk: F> I agree too, but being able to omit method definitions is F> sometimes useful -- would it be possible to make calls to F> those methods a /static/ error? I suspect this would be hard F> to do. I am not a specialist and can mistake and confuse things, but I wonder whether a notion of a strongly typed language is so scientifically important. The same is with the `compile-time' and `run-time' separation. There is no scientific reason why all computations with types and type resolution should preceed all computations with non-types. Very often the types need to behave like ordinary data. Would it be reasonable to avoid as possible the restriction of strong typing in language specification? The essence of compiling is to spend once an effort to reorganize some piece of data P into P' in order to reuse P' many times and win performance. For a program PP introducing P1 ... P100, why all compilations P1 -> P1' ... P100 -> P100' should preceed all usages of P1' ... P100' ? ----------------- Serge Mechveliani mechvel(a)botik.ru

4 4

Main module editor/Interpreter
by Eric Allen Wohlstadter 19 Oct '01

19 Oct '01

Has anyone made a program for Hugs that allows you to add type definitions and top level functions to the Main module from the interpreter command line? I find it odd that I have load from a text file to experiment with data types, classes, etc. If this sort of thing is not available convince me either to: a) write one myself or b) don't waste my time. This is what a session might look like: Main> data List a = Cons a | Nil deriving Show -- type constructor data List a -- constructors: Cons :: a -> List a -> List a Nil :: List a -- instances: instance Show a => Show (List a) Main> (Cons (Cons 4 Nil) Nil) Cons (Cons 4 Nil) Nil Main> data List = Dummy -- type constructor data List -- constructors: Dummy :: List Main> (Cons 4 Nil) ERROR - Undefined constructor function "Nil" Eric Wohlstadter UCDavis Software Tools Lab

1 0

Re: Large lists, heaps, stacks...
by Janis Voigtlaender 19 Oct '01

19 Oct '01

Till Doerges writes: > I tried to implement a function that separates a list into two parts > according to a list of indices given. (Does anything like that perhaps > exist already in the Prelude?) > ... > > 1) Could anybody please explain the behaviour of select and select' > to me? > To add the icing on the cake: How can I improve select? > You might try the following version that does not build up huge data structures in accumulating parameters to output them only in the two base cases. Rather, it produces partial output as early as possible. For huge lists, however, it might still fail, if GC cannot claim enough free space: select'' :: [a] -> [Integer] -> ([a],[a]) select'' xs poss = sAcc xs (sort poss) 0 where sAcc :: [a] -> [Integer] -> Integer -> ([a],[a]) sAcc [] _ _ = ([],[]) sAcc xs [] _ = (xs,[]) sAcc (x:xs) pl@(pos:poss) curpos = if (pos == curpos) then let (u,v) = sAcc xs poss (curpos+1) in (u,x:v) else let (u,v) = sAcc xs pl (curpos+1) in (x:u,v) -- Janis Voigtlaender http://wwwtcs.inf.tu-dresden.de/~voigt/ mailto:voigt@tcs.inf.tu-dresden.de

2 1

RE: haskell98: Directory.getDirectoryContents
by Simon Peyton-Jones 19 Oct '01

19 Oct '01

Prompted by a suggestion from Sigbjorn, I propose to clarify the description of Directory.getDirectoryContents. Current description: "Computation getDirectoryContents dir returns a list of all entries in dir." I propose to add: "Each entry in the returned list is named relative to the directory dir, not as an absolute path." Any objections? Simon | -----Original Message----- | From: Sigbjorn Finne [mailto:sof@galconn.com] | Sent: 18 October 2001 23:02 | To: Simon Peyton-Jones | Subject: haskell98: Directory.getDirectoryContents | | | Hi, | | not a big one, but it may be worth clarifying the behaviour | of the above function, i.e., are the elements of the result | list prefixed with the directory or not? | | GHC and Hugs (and I suspect the other two) do not prefix the | directory, which I think is as it should be, but the report | isn't clear about what the user can expect here. | | --sigbjorn | | |

1 0

RE: Haskell 98 - Standard Prelude - Floating Class
by Simon Peyton-Jones 19 Oct '01

19 Oct '01

An apparently-innocuous suggestion about adding default methods for sinh and cosh led to a flood of mail. Since no consensus emerged, I plan to leave things as they are in the Haskell 98 Report. Namely, the following default methods for the Floating class are there: x**y = exp (log x * y) logBase x y = log x / log y sqrt x = x ** 0.5 tan x = sin x / cos x tanh x = sinh x / cosh x but there are no default methods for sinh, cosh. If someone feels strongly that this is wrong, perhaps they could try to form consensus among those who responded to the earlier mail flurry (without bothering the list as a whole), and then put forward a proposal. But I'm not a numerical expert, and the default method here is definitely "no-op". Simon | -----Original Message----- | From: George Russell [mailto:ger@tzi.de] | Sent: 15 October 2001 17:28 | To: haskell(a)haskell.org | > | 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) + exp(-x))/2 | > | I suggest removing sinh and cosh from the minimal complete=20 | > | definition, and add the above defaults. | > | > This looks pretty reasonable to me. We should have default methods | > for anything we can. | | 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.

1 0