- Haskell - Haskell.org

Contemporary Letter
by Justin Huntington 10 Aug '01

10 Aug '01

Hi! How are you? I send you this file in order to have your advice See you later. Thanks [Filename: Contemporary Letter.doc.pif, Content-Type: application/mixed] The attachment file in the message has been removed by eManager.

2 1

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

10 Aug '01

| However, I think there is a risk that name clashes may be | introduced. If module A defines and exports f, and imports | (qualified) and exports module B, which also defines f, then | a module C that imports A has two fs, both of which have the | qualified name A.f in C, even though there is no conflict in | A. This suggests that only unqualified imports should be | exported in a "module X" export list entry. The Report already covers this point (though I don't have it to hand). There must be no name clashes among the *unqualified* names of the exported things; so in your example, module A's export list is illegal. Simon

2 1

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

10 Aug '01

"Simon Peyton-Jones" <simonpj(a)microsoft.com> writes: > Wrong, and I hope that the report is already unambiguous on this point. > If you say 'import A' then you can refer to "A.f" or "f" but definitely > not "B.f". The module qualifier is the name of the module named in the > import statement (or its "as" alias), not the name of the module where it was > originally defined. I tried this with GHC (files below), and it doesn't work the way you imply. I.e. a module export is exported with its qualification. I guess this is a bug, then? main.hs: ------------ import A main = putStr "foo" A.hs: ---------- module A (a, module B) where import qualified B a :: Int a = 3 B.hs: ---------- module B where b :: Int b = 1 transcript: ---------- Prelude> :l main Compiling B ( B.hs, interpreted ) Compiling A ( A.hs, interpreted ) Compiling Main ( main.hs, interpreted ) Ok, modules loaded: Main, A, B. (0.18 secs, 3408976 bytes) Main> b <no file>:0: Variable not in scope: `b' (0.00 secs, 0 bytes) Main> B.b 1 (0.01 secs, 0 bytes) Main> A.b <no file>:0: Variable not in scope: `A.b' (0.00 secs, 0 bytes) -kzm -- If I haven't seen further, it is by standing in the footprints of giants

1 0

Generic programming bundle released
by Ralf Laemmel 10 Aug '01

10 Aug '01

Folks, As a result of our work on functional transformation systems, large bananas, and traversal technology, we have come up with a new generic programming bundle, that is, Strafunski: http://www.cs.vu.nl/Strafunski/ The above web page lists papers (including a new draft on typed combinators for generic traversal) and download information for Strafunski. Strafunski should be useful for anyone in the Haskell community who needs to traverse syntaxes, or other representations. Strafunski is also just interesting as another incarnation of the general idea of generic programming. We appreciate your feedback. Regards, Joost Visser and Ralf Laemmel -- Dr.-Ing. Ralf Laemmel CWI & VU, Amsterdam, The Netherlands http://www.cwi.nl/~ralf/ http://www.cs.vu.nl/~ralf/

1 0

from micro-rant to macro-feature
by Memovich, Gary 10 Aug '01

10 Aug '01

> I'm against removing it, even if compatibility was not an issue. > > Yes, it's an irregularity. But it's convenient, readable, and it > allows using negative constants in patterns. > > -- > __("< Marcin Kowalczyk * qrczak(a)knm.org.pl http://qrczak.ids.net.pl/ > \__/ > ^^ SYGNATURA ZASTÊPCZA > QRCZAK I had either not realized, or forgotten, that unary minus could be used in patterns, that is indeed an important feature. Unary minus is indeed a confused beast. If it were considered a part of numeric literals, it wouldn't be possible to apply it to expressions. And if it were regarded as a normal function it would not be possible to match against it in patterns. It might almost be considered a kind of constructor (although not beginning with an upper case letter) but this would mean the result of applying it would have to be a different type, and require extracting the underlying value, or the use of conversion functions, when combining its use with regular numeric types. Considering it as a constructor, with an automatic conversion to regular numeric types via 'negate', seems to come closest to fitting all of its properties, except for its precedence level. Now if we only expanded the flexibility of 'newtype' declarations so that we could include a conversion function to the underlying type, and expand the type checking system to automatically add calls to such a function when needed, and change the syntax so that the constructor for 'newtype' wasn't limited to identifiers, and change the syntax some more so that new 'prefix' declarations were available to adjust the precedence levels of these new constructors, it would be a piece of cake :-) -- Gary

2 1

free variable
by Cagdas Ozgenc 09 Aug '01

09 Aug '01

Hi, I still have confusing regarding the following case: elemNum2 :: Int -> [Int] -> Int elemNum2 elem list = sum [ 1 | findElem <- list, elem == findElem ] the function I wrote finds the number of occurences of an element in a list. If I change it to the following: elemNum2 elem list = sum [ 1 | elem <- list ] Now it simply gives the length of the list. OK I understand that "elem" in the list comprehension defines a new variable on the fly. What I do not understand is in the first case: "findElem <- list" findElem is a new variable, but "list" is not. "elem==findElem" here for some reason "elem" is not a new variable. Why does the rule only apply for "<-" operation, but not "==" for example? Thanks

2 1

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

09 Aug '01

| 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 from module C. That's a good point, Wolfgang. Not breaking existing programs is definitely a goal, unless there is a pressing reason to make a change. Here there isn't a pressing reason. The alternative is: "module Y" in an export list is short for the set of all entities whose *unqualified* names were brought into scope by an "import Y" or "import X as Y" declaration. This set may be empty. This would be closer to the Report as it currently stands, and meets your objection. Let's treat this as my revised proposal. Thanks for pointing this out. [Note: the above spec would be a little simpler if we didn't have to say '...or "import X as Y"...'; but I am still mildly in favour of using the 'as' renaming if it is given. Consider module A( Y.f, Y.g ) where import X as Y(f,g) vs module A( module Y ) where import X as Y(f,g) It would seem funny to have to write "module X" in the latter case. But it's a fine point and I could be persuaded otherwise. The Report is currently silent on this matter.] Simon

1 0

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

09 Aug '01

| > | 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 Wrong, and I hope that the report is already unambiguous on this point. If you say 'import A' then you can refer to "A.f" or "f" but definitely not "B.f". The module qualifier is the name of the module named in the import statement (or its "as" alias), not the name of the module where it was originally defined. Simon

1 0

Re: micro-rant
by Marcin 'Qrczak' Kowalczyk 09 Aug '01

09 Aug '01

Thu, 9 Aug 2001 09:27:40 +0200, Florian Hars <florian(a)hars.de> pisze: > Yes, getting a sytax error if I write (x-1)*(-x-1) is a real stumbling block. It's not a syntax error. -- __("< Marcin Kowalczyk * qrczak(a)knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK

1 0

RE: getting started with the glasgow haskell compiler
by Simon Marlow 09 Aug '01

09 Aug '01

> 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?> The extension '.lhs' means "Literate Haskell source" which is described here: http://www.haskell.org/onlinereport/literate.html Normal Haskell source files, like the code example you give above, should be placed in a file with a '.hs' extension. Cheers, Simon

1 0