August 2001 - Haskell

RE: Modules (again)
by Simon Marlow 30 Aug '01

30 Aug '01

> Section 5.2 (Export lists) doesn't anticipate this question; note the > separation between items (5) and (6), whose wording I reproduce below. > > Thus provoked, I have come up with another formulation that simplifies > the specification, and evades both this problem and others. > Here it is: > > Replace (5) and (6) by: > > (5') The form 'module M' abbreviates the set of all entities > whose unqualified name, 'e', is in scope, and for which > the qualified name 'M.e' is also in scope. This set may > be empty. > > It is an error to use module M in an export list unless M is > the module bearing the export list, or M is imported by at > least one import declaration (qualified or unqualified). Am I the only one that thinks it's strange that module M ( module A ) where import B as A exports the contents of module B? A isn't even a module! The old definition claims that 'module M where' is the same as 'module M (module M) where' which is a nice property. Perhaps we can clarify the definition so that this is the case. One way to do this is to make 'module M' exports refer to the actual module M, not including any modules renamed to M. Since module names are unique, this is a much simpler formulation and doesn't end up exporting entities from several different modules. I suggest just changing the phrase "or `import A as M [impspec]'" to "or `import M as A [impspec]'" in point (5). Note that this change is slightly strange in a different way - exporting 'module M' doesn't necessarily export the entities which can be referred to by 'M.foo'. Anyway, I thought I'd throw this out as an alternative. Cheers, Simon

1 0

Re: Modules (again)
by Marcin 'Qrczak' Kowalczyk 30 Aug '01

30 Aug '01

Thu, 30 Aug 2001 00:56:25 -0700, Simon Peyton-Jones <simonpj(a)microsoft.com> pisze: > As you gather your wits for ICFP, you may like to consider the following > nice point (thanks to the OGI folk) in the Haskell 98 Report. Is > the following legal? And if so, what is exported? > > | module M(module M) where > | import A as M Legal. Exported is everything defined in this module and everything exported from A. Unless there are name conflicts, when it's an error. Now let's see if it agrees with your proposal: > The second paragraph is unchanged. The first paragraph encapsulates > rather neatly what we want. It answers questions like the one I opened > with (answer: all local defns and everything imported from A is > exported). Yes! I like your formulation. -- __("< Marcin Kowalczyk * qrczak(a)knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK

1 0

Re: Prefix negation
by Marcin 'Qrczak' Kowalczyk 30 Aug '01

30 Aug '01

Wed, 29 Aug 2001 16:34:52 +0200, Rijk-Jan van Haaften <rjchaaft(a)cs.uu.nl> pisze: > -3 ^ 2 = -9 > > In most programming languages as well as in mathematics > it is quite unusual to have infix operators with a higher > priority than prefix operators. In mathematics the prefix negation is handled like in Haskell: 2 -3 = -9 I agree that many languages got it wrong :-) -- __("< Marcin Kowalczyk * qrczak(a)knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK

2 1

Modules (again)
by Simon Peyton-Jones 30 Aug '01

30 Aug '01

Folks, As you gather your wits for ICFP, you may like to consider the following nice point (thanks to the OGI folk) in the Haskell 98 Report. Is the following legal? And if so, what is exported? | module M(module M) where | import A as M Section 5.2 (Export lists) doesn't anticipate this question; note the separation between items (5) and (6), whose wording I reproduce below. Thus provoked, I have come up with another formulation that simplifies the specification, and evades both this problem and others. Here it is: Replace (5) and (6) by: (5') The form 'module M' abbreviates the set of all entities whose unqualified name, 'e', is in scope, and for which the qualified name 'M.e' is also in scope. This set may be empty. It is an error to use module M in an export list unless M is the module bearing the export list, or M is imported by at least one import declaration (qualified or unqualified). The second paragraph is unchanged. The first paragraph encapsulates rather neatly what we want. It answers questions like the one I opened with (answer: all local defns and everything imported from A is exported). Comments? Simon ========================= The current wording: (5) The form `module M' abbreviates the set of all entities whose names are brought into scope by one or more unqualified import declarations of the form `import M [impspec]' or `import A as M [impspec]'. This set may be empty. For example: module Queue( module Stack, enqueue, dequeue ) where import Stack ... Here the module Queue uses the module name Stack in its export list to abbreviate all the entities imported from Stack. (6) Additionally, a module can name its own local definitions in its export list using its name in the `module m' syntax. For example: module Mod1(module Mod1, module Mod2) where import Mod2 import Mod3 Here module Mod1 exports all local definitions as well as those imported from Mod2 but not those imported from Mod3. Note that module M where is the same as using module M(module M) where It is an error to use module M in an export list unless M is the module bearing the export list, or M is imported by at least one import declaration (qualified or unqualified).

1 0

Hiding non-existent entities
by Simon Marlow 30 Aug '01

30 Aug '01

The Haskell 98 errata page currently contains this item related to a hiding clause on an import declaration which refers to a non-existent entity: [Aug 2001] Page 66, Section 5.3, Import Declarations, numbered item 2. Add "It is not an error to hide an entity that is not, in fact, exported by the imported module, although compilers are encouraged to flag a warning in this case." (This is different from what I proposed by email, which made this case an error, but it allow a bit more flexibility as modules change.) IMO allowing a hiding clause to refer to a non-existent entity is a bit odd. Haskell doesn't have any other features like this: it's always an error to refer to an entity that isn't defined anywhere, even if the reference is otherwise harmless. Does anyone else have any opinions on this? Cheers, Simon

2 1

Efficient way to perform independent processing of list from IO?
by mctague＠one.net 29 Aug '01

29 Aug '01

Hi, I've written a program that reads in a list of things from stdin and performs an independent computation on each one and prints the results as a list back to stdout. I've implemented it as in the following simple example: import IO getIntsFromHandle :: Handle -> IO [Int] getIntsFromHandle handle = do string<-hGetContents handle return (read string) writeToHandle :: (Show a)=> a -> Handle -> IO () writeToHandle x handle = do hPutStr handle (show x) hClose handle main :: IO () main = do ints<-getIntsFromHandle stdin writeToHandle (map (^2) ints) stdout but with this approach, all the data are read before they are written, or at least so it seems from memory utilization and by using the keyboard interactively to type into stdin. Is there a more memory-efficient approach, perhaps exploiting laziness somehow? Thanks, Carl

2 1

Re: Efficient way to perform independent processing of list from IO?
by Marcin 'Qrczak' Kowalczyk 29 Aug '01

29 Aug '01

Wed, 29 Aug 2001 12:07:47 -0600, mctague(a)one.net <mctague(a)one.net> pisze: > return (read string) > but with this approach, all the data are read before they are written, read is the problem. It wants to see if the whole string can be parsed before deciding whether to deliver a result or signal error. It can be solved by manually splitting the input (e.g. on commas, stripping also initial '[' and final ']') and reading each part separately. -- __("< Marcin Kowalczyk * qrczak(a)knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK

1 0

Re: Prefix negation
by Pixel 29 Aug '01

29 Aug '01

"Marcin 'Qrczak' Kowalczyk" <qrczak(a)knm.org.pl> writes: > Wed, 29 Aug 2001 16:34:52 +0200, Rijk-Jan van Haaften <rjchaaft(a)cs.uu.nl> pisze: > > > -3 ^ 2 = -9 > > > > In most programming languages as well as in mathematics > > it is quite unusual to have infix operators with a higher > > priority than prefix operators. > > I agree that many languages got it wrong :-) many languages have it the haskell way: -9: perl, ruby, python, haskell 9: ocaml > In mathematics the prefix negation is handled like in Haskell: > > 2 > -3 = -9 -3^2 = -9 doesn't bother me -3 ^ 2 = -9 do bother me :-(

1 0

Prefix negation
by Rijk-Jan van Haaften 29 Aug '01

29 Aug '01

Section 3.4 (Expressions.Operator applications) of the language report, says this about prefix negation: Prefix negation has the same precedence as the infix operator - defined in the Prelude (see Table 1). This is not what I expected (and not what other languages mostly do). One of the consequences is that -3 ^ 2 = -9 In most programming languages as well as in mathematics it is quite unusual to have infix operators with a higher priority than prefix operators. Why is this rule chosen in Haskell? Thanks in advance, Rijk-Jan

1 0

Re: ANN: C->Haskell 0.9.9 "Blue Ginger"
by Marcin 'Qrczak' Kowalczyk 29 Aug '01

29 Aug '01

Wed, 29 Aug 2001 15:20:55 +1000, Manuel M. T. Chakravarty <chak(a)cse.unsw.edu.au> pisze: > Thanks for pointing it out. It is, however, strictly a Gtk+HS > problem. C->Haskell already deals with GHC's new convention. They were both in a gtk+hs's own .hs file and in foreign calls produced from .chs by c2hs-0.9.9. -- __("< Marcin Kowalczyk * qrczak(a)knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK

1 0