July 2001 - Haskell - Haskell.org

Haskell-JNI Bridge
by Ashley Yakeley 05 Jul '01

05 Jul '01

Is Lambada (the Haskell-JNI bridge) gone? The web-page has disappeared. Using Java seems by far the most obvious way of getting all that GUI/network/SQL/whatever functionality, especially as the Java platform is almost ubiquitous (unlike .NET, Tk, X, GTK+, Win32 GDI, etc.). In this apparent absence I'm writing my own Haskell-JNI bridge. So far, I can get code compiled with GHC 5 on Linux to call static Java methods (such as the 'main' method of an application class) and some other stuff such as create arrays. Phase 1 is to add the rest of the JNI functions (easy, but time-consuming). Phase 2 is to figure out how to create classes on the fly that can call back to Haskell. Fortunately Java does provide functions for loading classes from a byte-array of bytecode. $ ./TestJNI Hello from Java! $ I intend to release it open source at some point. -- Ashley Yakeley, Seattle WA

3 2

RE: infelicity in module imports
by Simon Peyton-Jones 05 Jul '01

05 Jul '01

| | > Currently, you are permitted to write | | > | | > import A hiding (f) | | > import B as A (f) | | > | | > and this means that everything exported from module A is visible, | | > with the exception that function `f' is overridden by a different | | > definition from module B. Here, a reference to `A.f' is resolved | | > unambiguously to `B.f'. | | | | In my understanding of the report, this is not true. Quoting from | | section 5.3 of the report | | | | "The hiding clause only applies to unqualified names. In the previous | | example, the name M.C is brought into scope." | | | | Thus, in your example, the declaration import A hiding (f) will bring | | A.f into scope and thus A.f is ambiguous! Wolfgang is correct. I don't see how the report can be read any other way. | However, if you are indeed correct, then we have an even stranger | situation: | | import A (g) | | brings only A.g into scope, but | | import A hiding (f) | | brings both A.f and A.g into scope! So `hiding' is doing the | opposite of hiding, and in fact _reveals_ names. No, that's not so. Let's assume that A exports f,g,h. The report says (first sentence of 5.3.1) "if the qualified keyword is omitted, both qualified and unqualified names are brought into scope". So both the above imports bring into scope A.f and A.g and A.h; the former also brings unqualified 'g' into scope, while the latter also brings 'g' and 'h' into scope. In short, an import *always* brings the entire *qualified* set of names into scope. Hiding and revealing applies only to unqualified names. I must say that I thought GHC implemented this rule; if not I should fix it. As to whether this is a good design, I'm sure one could suggest others, but I'm very strongly biased against fixing anything that is not a Bug. As to whether it is clearly stated, presumably the answer is 'no', since Malcolm (an expert by any lights) has misunderstood it in two different ways. That I would like to fix. Can anyone suggest a way to make the report clearer? Simon

2 1

RE: infelicity in module imports
by Simon Marlow 05 Jul '01

05 Jul '01

Simon Peyton Jones writes: > In short, an import *always* brings the entire *qualified* > set of names into scope. Hiding and revealing applies only > to unqualified names. I must say that I thought GHC implemented > this rule; if not I should fix it. That's not my reading of the report, and it's not what GHC implements. import A (f) brings only f and A.f into scope. Relevant quotes from the report, section 5.3.1: "An import declaration that uses the qualified keyword brings into scope only the qualified names of the imported entities (Section 5.5.1); if the qualified keyword is omitted, both qualified and unqualified names are brought into scope" and section 5.5.1: "An import declaration, whether qualified or not, always brings into scope the qualified names of the imported entity." [ aside: should that last word be "entities"? ] I'm taking the term "the imported entities" to mean those entities specified in the import list, or all the exported entities if the import list is omitted. If it doesn't mean this, what's the point of allowing import specifications on a qualified import? If it does mean this, then GHC is correct, but the report's comments about the effect of hiding on qualified names is inconsistent and should be removed (GHC doesn't implement this rule either). Perhaps this is the wrong interpretation, and Simon's is the correct one. But no where that I can find does the report say that an import always brings into scope *all* the qualified names from the imported module regardless of the import list. Cheers, Simon

2 1

Negatively recursive data types
by Keith Wansbrough 05 Jul '01

05 Jul '01

Hi... I'm currently looking at the semantics of recursive data types. One thing that Haskell allows, but the semantics for it is very hairy, is *negatively* recursive data types. That is, data types where the recursion occurs to the left of a function arrow. For example: data Neg a b = MkNeg (a -> Neg a b -> b) Here (Neg a b) occurs to the left of the function arrow. Some members of this data type might be: n1, n2 :: Neg Int [Int] n1 = MkNeg (\ x _ -> [x]) n2 = MkNeg (\ x (MkNeg f) -> x : f (x+1) n1) This example is not a very good one. Does anyone have an example of a useful data type involving negative recursion? Thanks. --KW 8-)

4 3

Good for a laugh!
by Kirk 05 Jul '01

05 Jul '01

Thought you'd like to take a break and laugh a little. The following site is updated daily and has funny news articles, quotes, and sections like Dog Thoughts and Headlines. It even has a Webcam! I'm sure you'll find something to enjoy. http://www.laundryday.com Spread the smiles. P.S. Please do not respond to this email. It's a one time mailing. :-)

1 0

Bindings and Space leaks
by Janis Voigtlaender 05 Jul '01

05 Jul '01

Hello, I've got two questions regarding bindings in Haskell: 1. Is there something like a strict "let!" for avoiding function closures by forcing strict evaluation (to headnormalform) of local declarations? 2. In a '93 paper, Jan Sparud describes an implementation technique for avoiding space leaks when tuples are returned as function result, and the values accessed by pattern matching in bindings. The paper says this technique (of shorcircuiting all references via a tuple, the first time a tuple element is demanded) has been implemented in Chalmers LML/HBC compiler. What about other compilers, e.g. GHC? Any hint would be helpful. Thanks, Janis. -- Janis Voigtlaender email: voigt(a)tcs.inf.tu-dresden.de

3 2

Re: infelicity in module imports
by Wolfgang Lux 04 Jul '01

04 Jul '01

Malcolm Wallace wrote > However, if you are indeed correct, then we have an even stranger > situation: > > import A (g) > > brings only A.g into scope, but > > import A hiding (f) > > brings both A.f and A.g into scope! So `hiding' is doing the opposite > of hiding, and in fact _reveals_ names. Yes, I agree that this is quite strange (and the keyword hiding is quite misleading in this case). Probably, it is the best idea to remove the restriction that hiding clauses apply only to unqualified names from the report as you and Simon are suggesting. Regards 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: infelicity in module imports
by Malcolm Wallace 04 Jul '01

04 Jul '01

| > Currently, you are permitted to write | > | > import A hiding (f) | > import B as A (f) | > | > and this means that everything exported from module A is visible, | > with the exception that function `f' is overridden by a different | > definition from module B. Here, a reference to `A.f' is resolved | > unambiguously to `B.f'. | | In my understanding of the report, this is not true. Quoting from section | 5.3 of the report | | "The hiding clause only applies to unqualified names. In the previous | example, the name M.C is brought into scope." | | Thus, in your example, the declaration import A hiding (f) will bring | A.f into scope and thus A.f is ambiguous! You are possibly correct, although both nhc98 and ghc actually resolve it in the manner I expected. However, if you are indeed correct, then we have an even stranger situation: import A (g) brings only A.g into scope, but import A hiding (f) brings both A.f and A.g into scope! So `hiding' is doing the opposite of hiding, and in fact _reveals_ names. Regards, Malcolm

1 0

infelicity in module imports
by Malcolm Wallace 04 Jul '01

04 Jul '01

I was considering submitting this as a bug report in the Haskell'98 definition, but I don't know whether that is the appropriate designation or not. In any case, I think it is probably caused by a hang-over from a previous version of Haskell that never caught up with the newer features added in '98. The problem is the combination of qualified imports, explicit hiding, and renamed imports with overlapping. Currently, you are permitted to write import A hiding (f) import B as A (f) and this means that everything exported from module A is visible, with the exception that function `f' is overridden by a different definition from module B. Here, a reference to `A.f' is resolved unambiguously to `B.f'. However, should you wish to do the same trick with all names forced to be qualified, it is not legal. import qualified A hiding (f) import qualified B as A (f) Although this looks like a very similar case, the standard says that a `hiding' clause has no effect on a qualified import. Hence, even though the programmer has clearly tried to make it non-ambiguous, a reference to `A.f' cannot be resolved between `A.f' and `B.f', and such a program is rejected. I submit that the way `hiding' clauses are ignored is a vestige from the days when it was not possible to have overlapped module renamings. Now that overlapped renamings are possible, the `hiding' clauses should be permitted to take effect. Regards, Malcolm

2 1

RE: infelicity in module imports
by Simon Marlow 04 Jul '01

04 Jul '01

Malcolm Wallace writes: > I submit that the way `hiding' clauses are ignored is a vestige from > the days when it was not possible to have overlapped module renamings. > Now that overlapped renamings are possible, the `hiding' clauses > should be permitted to take effect. I think you're right. It's inconsistent that you can specify which qualified identifiers are imported using 'import A ( foo, bar )' but not using the hiding form. The following two sentences could just be deleted from point 2, section 5.3: "The hiding clause only applies to unqualified names. In the previous example, the name M.C is brought into scope. A hiding clause has no effect in an import qualified declaration." Cheers, Simon

1 0