- Haskell - Haskell.org

CFP: JFP on SAIG
by Walid Taha 08 Jul '01

08 Jul '01

CALL FOR PAPERS A Special Issue of JFP on Semantics, Applications, and Implementation of Program Generation http://cs-www.cs.yale.edu/~taha/saig/jfp.html Program generation has the prospect of being an integral part of a wide range of software development processes. Recent studies investigate different aspects of program generation systems, including their semantics, their applications, and their implementation. Existing theories and systems address both high-level (source) language and low-level (machine) language generation. A number of programming languages now support program generation and manipulation. These languages can have different goals, use different different implementation techniques, and target different applications. In this context, a PLI workshop dedicated to this theme (SAIG'00) was held this year. Following on from this workshop, a special issue of the Journal of Functional Programming will be devoted to the same theme. Full-length, archival-quality submissions are solicited on topics including both theoretical and practical models and tools for building program generation systems, Examples include: * Semantics, type systems, and implementations for multi-stage languages. * Run-time specialization systems: e.g. compilers, operating systems. * High-level program generation (applications, foundations, environments). * Symbolic computation, linking and explicit substitution, in-lining and macros. Reports on applications of these techniques to real-world problems are especially encouraged, as are submissions that relate ideas and concepts from several of these topics, or bridge the gap between theory and practice. Contributors to SAIG'00 are encouraged to submit, but submission is open to everyone. Papers will be reviewed as regular JFP submissions, and acceptance in the special issue will be based on relevance to the theme. The special issue also welcomes high-quality survey and position papers that would benefit a wide audience. Accepted papers exceeding the space restrictions will be published as regular JFP papers. Submissions should be sent to the guest editor (address below), with a copy to Nasreen Ahmad (nasreen(a)dcs.gla.ac.uk) Submitted articles should be sent in postscript format, preferably gzipped and uuencoded. In addition, please send, as plain text, title, abstract, and contact information. The submission deadline is February 1st, 2001. For other submission details, please consult an issue of the Journal of Functional Programming or see the Journal's web page at http://www.dcs.gla.ac.uk/jfp/. Guest Editor Editor in Chief Walid Taha Department of Computer Science Philip Wadler Yale University Avaya Labs P.O. Box 208285 700 Mountain Ave, Room 2T-402, New Haven, CT 06520-8285, Murray Hill, NJ 07974-0636, USA. USA. Email: taha(a)cs.yale.edu Email: wadler(a)avaya.com Phone: +1 203 432 6496 Phone: +1 908 582 4004 Fax : +1 203 432 0593 Fax: +1 908 582 5857

1 5

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