August 2001 - Haskell

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

CFP: ICLP ws SAVE 2001
by Giorgio Delzanno 03 Aug '01

03 Aug '01

=============================================================================== We apologize for multiple copies of this message =============================================================================== ICLP 2001 workshop SAVE 2001 Specification, Analysis and Validation for Emerging Technologies in Computational Logic http://www.disi.unige.it/person/DelzannoG/save.html Dec 1, 2001 , Coral Beach Hotel and Resort, Paphos, Cyprus Submission Deadline: August 25, 2001 The huge increase in interconnectivity we have witnessed in the last decade has boosted the development of systems which are often large-scale, distributed, time-critical, and possibly acting in an unreliable or malicious environment. Furthermore, software and hardware components are often mobile, and have to interact with a potentially arbitrary number of other entities. These systems require solid formal techniques for their verification and analysis. In this respect, computational logic plays an increasingly important role, both providing formal methods for proving system's correctness and tools - e.g. using techniques like constraint programming and theorem proving - for verifying their properties. In addition, computational logic is gaining importance as tool for the specification of (part) of these systems. For instance, one can think at the specification, in a form of temporal logic, of a communication protocol. Such specification offers the advantage that one can reason about it using formal methods, and at the same time it is often easily executable by rewriting it into a logic-based programming language. Extending and shifting slightly from the scope of the predecessors (on verification and logic languages) held in the context of past editions of ICLP, the aim of this workshop is to bring together researchers interested in the use of computational logicas a tool for the specification, analysis and validation of systems, with particular emphasis on (but not restricted to) emerging technologies like World Wide Web and E-Commerce, (protocols for) Smart Cards and Mobile Telephony, Wireless Technology, Hybrid Systems, Real-Time and Distributed systems etc. Topics The topics of interest include but are not limited to: Specification languages and rapid prototyping: Logic programming and its extensions First-order, constructive, modal and temporal logic Constraints Type theory Analysis: Abstract interpretation Static analysis Validation: Simulation and testing Deductive methods Model checking Theorem proving The preferred issues include, but are not limited to: Mobility: specification and verification of mobile code. Security: access rights, information flow, and security protocols. Interaction, coordination, negotiation, communication and exchange on the Web. Open and infinite-state systems. Real-time systems. Important Dates: Deadline for submissions: August 25, 2001. Notification of acceptance/rejection: September 15, 2001. Final papers due: October 5, 2001. Authors should submit papers of at most 15 pages, in postscript format, formatted for A4 paper, to Giorgio Delzanno (giorgio(a)disi.unige.it) by the 25th of August 2001. The proceedings will be published in electronic format. A printed version will be distributed to all participants of the workshop. On the basis of the number and quality of the submissions, we could also consider the possibility of inviting submissions for a special issue of an international journal dedicated to the workshop. Workshop Organizers/PC Chairs: Giorgio Delzanno Dipartimento di Informatica e Scienze dell'Informazione Universita' di Genova giorgio(a)disi.unige.it Sandro Etalle Department of Computer Science University of Twente and CWI etalle(a)cs.utwente.nl Maurizio Gabbrielli Dipartimento di Matematica ed Informatica Universita' di Udine gabbri(a)dimi.uniud.it Program Committee: Radhia Cousot, CNRS & École Polytechnique, France Giorgio Delzanno, University of Genova, Italy Sandro Etalle, University of Twente and CWI, The Netherlands Maurizio Gabbrielli, University of Udine, Italy Thierry Massart, University of Brussels, Belgium Frank Pfenning, Carnegie Mellon University, USA Andreas Podelski, Max Planck Institute, Germany Sriram Rajamani, Microsoft Research, USA Jean-Francois Raskin, University of Brussels, Belgium

1 0

Re: Haskell-JNI Bridge
by Ashley Yakeley 03 Aug '01

03 Aug '01

At 2001-07-05 02:23, I wrote: >In this apparent absence I'm writing my own Haskell-JNI bridge. This now has a home at <http://sourceforge.net/projects/jvm-bridge/>, and I'm licensing it under LGPL. -- Ashley Yakeley, Seattle WA

1 0

RE: How do you stop functions being inlined?
by Simon Marlow 02 Aug '01

02 Aug '01

In fact, GHC understands both NOINLINE and NOTINLINE with any capitalisation. We just tend to use NOINLINE because I think GHC had it before notInline was mentioned in the report. Cheers, Simon > -----Original Message----- > From: Julian Seward (Intl Vendor) [mailto:v-julsew@microsoft.com] > Sent: Thursday, August 02, 2001 10:31 AM > To: George Russell; haskell(a)haskell.org > Subject: RE: How do you stop functions being inlined? > > > > {-# NOINLINE name #-} > > | -----Original Message----- > | From: George Russell [mailto:ger@tzi.de] > | Sent: Wednesday, August 01, 2001 3:46 PM > | To: haskell(a)haskell.org > | Subject: How do you stop functions being inlined? > | > | > | Well, I think we all know the answer to this one, namely > | {-# NOINLINE [name] #-} > | This is, after all, what GHC does, and what several of the > | files in ghc/fptools do. > | > | Only slight problem is that according to the Haskell 98 > | report, including Simon Peyton Jones' revised draft, you > | should use: > | {-# notInline [name] #-} > | Most of the time in fptools/hslibs (which I have from > | GHC), NOINLINE is used, but in one case notInline is used. > | > | Of course one of the delights of pragmas is that the > | "pragma should be ignored if an implementation is not prepared to > | handle it.". So if you guess wrong, you may never know, > | until you get a mysterious bug from GHC inlining a call to > | create a global variable via unsafePerformIO. Aren't pragmas > | wonderful? > | > | Would someone tell me which we are supposed to use? Or > | should I use both "NOINLINE" and "notInline", just to be on > | the safe side? > | > | _______________________________________________ > | Haskell mailing list > | Haskell(a)haskell.org http://www.haskell.org/mailman/listinfo/haskell > | > > _______________________________________________ > Haskell mailing list > Haskell(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell >

2 1

Re: lexical description problem in language report?
by Wolfgang Lux 02 Aug '01

02 Aug '01

Thomas Hallgren wrote > There seems to be a similar problem with qualified identifiers. The > production for lexeme includes varid, conid, etc, rather than qvarid, > qconid, etc. (Perhaps someone forgot to update it when qualified names > were introduced, in Haskell 1.3...) Sorry we must have a different version of the report, but in my copy and also in the version on Simon PJ's web-pages section 2.4 (in the last paragraph) and appendix B include productions for the qualified identifiers. Wolfgang -- Wolfgang Lux Phone: +49-251-83-38263 Institut fuer Wirtschaftinformatik FAX: +49-251-83-38259 Universitaet Muenster Email: wlux(a)uni-muenster.de

4 3