- Haskell - Haskell.org

getting started with the glasgow haskell compiler
by Johansson Mikael 09 Aug '01

09 Aug '01

Hello! I'm just getting started using the glasgow haskell compiler and when I try to compile a simple program, named Hello.lhs, like this: module Main (main) where main = putStrLn "Hello World" end with the command ghc Hello.lhs I get the message on standard output: No definitions in file <perhaps you forgot the '>'s?> Where can I find working example files? regards Mikael Johansson Control System Engineer Performance and control Volvo Aero Corporation Military Engines Trollhättan Dept. 7164MJ SE-461 81 Trollhättan, Sweden phone +46 520 940 61 e-mail: mikael.mj.johansson(a)volvo.com

2 1

Re: micro-rant
by Richard Watson 09 Aug '01

09 Aug '01

On Wed, 8 Aug 2001, Wolfgang Jeltsch wrote: > I totally agree with Gary. In my opinion the unary minus is a anomaly in > Haskell which causes a lot of problems while beeing not that useful. For me > it is totally okay to use negate x instead of -x. > > Gary wrote: > > <micro-rant> > > As long as were trying to clean up a final version of the Haskell 98 > > report, lets simplify it a little by getting rid of unary minus. > > It's the only prefix operator in the whole language. I'd like to add my vote for this. Its removal would result in a nicer language specification, and would remove a obstacle that novice programmers sometimes stumble over. Richard

2 1

(no subject)
by Vincent Tseng 08 Aug '01

08 Aug '01

hi does anyone know how to do this ? a function that will "randomly" takes elements from a list eg randomPick 3 ['a','b','c','d','e'] = ['d','a','a'] thanks

3 2

micro-rant
by Memovich, Gary 08 Aug '01

08 Aug '01

Hello people, I've been studying the Haskell 98 report as part of my study of the Haskell language and need to rant just a little bit. <micro-rant> As long as were trying to clean up a final version of the Haskell 98 report, lets simplify it a little by getting rid of unary minus. It's the only prefix operator in the whole language. It requires messing up the otherwise clean expression syntax. It has a meaning that the user can't change, very rare in Haskell. It even has a fixed precedence level. It leads to excessive confusion when dealing with sections involving '-' (the binary operator). Uses can be replaced by either negate x or 0-x. </micro-rant> I know we can't actually remove unary minus at this point, I just had to get this off my chest. -- Gary

2 1

Thanks: Inferred type is not general enough
by Cagdas Ozgenc 08 Aug '01

08 Aug '01

Thanks to all who responded.

1 0

Re: Inferred type is not general enough
by Ketil Malde 08 Aug '01

08 Aug '01

"Cagdas Ozgenc" <co19(a)cornell.edu> writes: > The following function generates a type error. > > headColumnwise :: [a] -> a > headColumnwise line = [ head line | line <- p ] Surely, the parameter should be "p"? > ERROR ch6ex1.hs:14 - Inferred type is not general enough > *** Expression : headColumnwise > *** Expected type : [a] -> a > *** Inferred type : [[a]] -> [a] > it compiles fine. Isn't [a]->a the most general type here? If p is [a], then line (drawn from p) must be of type a. But you do "head line", which implies that line (and thus a) is a list. -kzm -- If I haven't seen further, it is by standing in the footprints of giants

1 0

Inferred type is not general enough
by Cagdas Ozgenc 08 Aug '01

08 Aug '01

Hi, The following function generates a type error. headColumnwise :: [a] -> a headColumnwise line = [ head line | line <- p ] ERROR ch6ex1.hs:14 - Inferred type is not general enough *** Expression : headColumnwise *** Expected type : [a] -> a *** Inferred type : [[a]] -> [a] If I change the type of the function to [[a]] -> [a] it compiles fine. Isn't [a]->a the most general type here? Thanks

1 0

Re: More feedback on Haskell 98 modules from the Programatica Team
by Wolfgang Lux 08 Aug '01

08 Aug '01

Simon Peyton-Jones wrote > | 2) The semantics of "module M" style entries in export lists seems to > | Program 2: module A(module B, ...) where > | ~~~~~~~~~~ import qualified B > | ... code that doesn't import B ... > | > | A similar example: now B appears as an import, but there are no > | unqualified imports of B, so either "module B" adds nothing to the > | export list (except instances?), or else this program is an error. > | > | Item 5 on p65 (describing entities exported from modules) says that > | "module m" exports entities brought into scope from m by one or > more > | *unqualified* imports. But this example suggests more; that it > will > | export instances brought into scope from *qualified* imports too. > | Perhaps the intention is that "module m" exports all instances, > | and all entities that are imported from m with an unqualified name? > > I don't think it should matter whether B is imported qualified or not; I > propose > to remove the *unqualified* adjective in the above quote. I don't think that this is a good idea. In particular because it may break existing programs. Consider two modules with one common name, e.g. module A where f x = 1 ... a lot of other definitions ... module B where f x = 2 ... a lot more definitions but none conflicting with A's top-level entities ... The following module is legal under the current semantics of the report (and will export everything from A and B except for A.f and in particular will generate no names clashes in the body of the module module C (module A,module B,module C) where import A hiding(f) import qualified A(f) import B ... code using A.f and f (i.e. B.f) ... With your proposed change there will be a name clash for the export of f from module C. 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

Re: More feedback on Haskell 98 modules from the Programatica Team
by Ketil Malde 08 Aug '01

08 Aug '01

"Simon Peyton-Jones" <simonpj(a)microsoft.com> writes: > I propose that hiding something that isn't exported should be > considered an error. It's not actually harmful but it is misleading. Or at least a warning? I don't know, but there may be reasons to do it, say the imported module is under development, and will eventually include that name. > | Program 2: module A(module B, ...) where > | ~~~~~~~~~~ import qualified B > | ... code that doesn't import B ... [...] > I don't think it should matter whether B is imported qualified or not; I > propose to remove the *unqualified* adjective in the above quote. ...but only allow qualified access to B by importers of A, right? I.e. import A B.b -- okay b -- not okay > The export list specifies what is exported, and can include qualified > names: > module A( B.f ) where > import qualified B But here, f will be avalable to importers of A, unqalified, no? GHC seems to do it this way, and I think it's a reasonable choice: If you need to automatically provide the full functionality of another module, you get it qualified (if you import it qualified); if you just want to extend your module with functionality from another one, you name each function. *Shrug* No strong feelings one way or another. -kzm -- If I haven't seen further, it is by standing in the footprints of giants

1 0

RE: More feedback on Haskell 98 modules from the Programatica Team
by Simon Peyton-Jones 07 Aug '01

07 Aug '01

Folks The folk at OGI have continued the current trend of discovering unspecified corners of Haskell 98. That means taking some decisions, and, as ever, I don't want to do that without giving you all a chance to demur. Nevertheless, I doubt this'll be controversial, because it's all dark-corner stuff. | 1) Sec 5.3.1: In an "import A(x, ...)", the report tells us | that x must be one of the names exported from A. There is no | indication whether a similar rule applies to declarations | like "import A hiding (x, ...)" if x is not exported from A. I propose that hiding something that isn't exported should be considered an error. It's not actually harmful but it is misleading. | 2) The semantics of "module M" style entries in export lists seems to | be underspecified. Here are some programs to illustrate: | | Program 1: module A(module B, ...) where | ~~~~~~~~~~ ... code that doesn't import B ... | | Is this valid? We thought that it should probably be invalid, | but could also see an interpretation in which it was valid, but | with nothing exported for the "module B" part. By the same token, I think this should be an error. | Program 2: module A(module B, ...) where | ~~~~~~~~~~ import qualified B | ... code that doesn't import B ... | | A similar example: now B appears as an import, but there are no | unqualified imports of B, so either "module B" adds nothing to the | export list (except instances?), or else this program is an error. | | Item 5 on p65 (describing entities exported from modules) says that | "module m" exports entities brought into scope from m by one or more | *unqualified* imports. But this example suggests more; that it will | export instances brought into scope from *qualified* imports too. | Perhaps the intention is that "module m" exports all instances, | and all entities that are imported from m with an unqualified name? I don't think it should matter whether B is imported qualified or not; I propose to remove the *unqualified* adjective in the above quote. The export list specifies what is exported, and can include qualified names: module A( B.f ) where import qualified B So 'module B' in an export list means "everything imported from B" regardless of whether the things imported from B are known by a qualified or unqualified name. | Program 3: module A(module B, ...) where | ~~~~~~~~~~ import B as C | ... code that doesn't import again from (or as) B ... | | Program 4: module A(module B, ...) where | ~~~~~~~~~~ import C as B | ... code that doesn't import again from (or as) B ... | | Which of these is valid? Does the "B" in "module B" refer to the | literal name of the module from which entities are imported, the | local alias by which they are referenced, ... or both? Good question! Given import X as Y module X is known as Y throughout the importing module, so [proposal] I think it should be module Y that appears in the export list, not X. So a good summary of what is exported by "module Y" would be "every entity e for which Y.e is in scope". [Recall that everything is always imported qualified, and perhaps unqualified too.] Simon

1 0