- Haskell - Haskell.org

RE: hiding imports
by Simon Peyton-Jones 05 Dec '01

05 Dec '01

I think it's an ill-thought-out exception. The point is this: if a data constructor cannot appear on its own in a hiding list, then you can't hide the constructor without hiding the type. Currently you can say import Maybe hiding( Just ) It would be simpler and more uniform to only allow data constructors inside parens, just as for exports, but then I'd have to say import Maybe hiding( Maybe(Just) ) and now the type constructor Maybe is hidden too. I say "ill thought out" because the exception doesn't actually solve the problem, as you point out. You may accidentally hide things you didn't mean to. So perhaps the cure is as bad as the disease. Changing this would be technically easy (delete a sentence) but it might break some programs, so that suggests the status quo. Simon | -----Original Message----- | From: Iavor S. Diatchki [mailto:diatchki@cse.ogi.edu] | Sent: 04 December 2001 19:14 | To: haskell(a)haskell.org | Subject: hiding imports | | | hello, | | i was wondering if there was a reasong why "hiding imports" | have different semantics from "importing imports" and | "exports". what i mean is, if one | writes: | | module A(T) where | data T = T | only the type constructor T is exported. simillarly if i write: | | module A where | data T = T | | module B where | import A(T) | | only the type constructor is imported, but if i write | (module A as above) | | module B where | import A hiding (T) | | both the type constructor and the value constructor are hidden. | | this seems not only irregular, but may also be inconvinient | in practise as sometimes it happens that a type constructor | and a data constructor have the same name, but the data | constructor does not "belong" to the type constructor. for example: | | module A where | type T = TGen Int | data TGen a = T a | S | | module B where | import A hiding (T) -- intending to just hide the type T | genF = T -- error T not in scope! | | so if i wanted to ignore the type T, but still have the data | constructor i | have to explicitly import it, i.e. write: | module B where | import A hiding (T) | import A (TGen(T)) | which is kind of ugly. is this strange behaviour for | historical reasons, | or was there a practical reason why this decision was made? | | bye | iavor | | | _______________________________________________ | Haskell mailing list | Haskell(a)haskell.org http://www.haskell.org/mailman/listinfo/haskell |

1 0

RE: Haskell 98 Revised
by Simon Peyton-Jones 05 Dec '01

05 Dec '01

A good point. You are right that the report is not very explicit on this point; and right that omitting the qualifier would be in the spirit of the story for type sigs and instance decls. I'd be interested to know what others think. Simon | -----Original Message----- | From: Iavor S. Diatchki [mailto:diatchki@cse.ogi.edu] | Sent: 04 December 2001 18:41 | To: haskell(a)haskell.org | Subject: Re: Haskell 98 Revised | | | hello, | | it seems that if the qualified names in instance declarations | are removed, the qualified methods (data constructors) in | exports ought to be removed as | well. example: currently in Haskell one may write | | module M ( P.C(Q.f) ) where | import qualified P | import qualified Q | ... | qualifying the method (or data cosntructor) does not give | any additional | information. however if i read the current report correctly | (and i don't | think it is quite clear on that) omitting the qualifier of | "f" results in an | invalid program as there is no method "f" in scope (there | probably are "P.f" | and "Q.f"however). having said that, GHC accepts the | program without the | qualifier,so it seems that it essentailly ignores the qualifiers of | "subordinate" names in export lists. so why not adjust the | report so that | such qualified names are just not allowed? | | bye | iavor | | | | | | | _______________________________________________ | Haskell mailing list | Haskell(a)haskell.org http://www.haskell.org/mailman/listinfo/haskell |

1 0

CFP: Special Journal Issue on Proof-Carrying Code
by Amy Felty 04 Dec '01

04 Dec '01

Call for Papers JOURNAL OF AUTOMATED REASONING Special issue on PROOF-CARRYING CODE Proof-carrying code is a technology that allows a host, or code consumer, to safely run code delivered by an untrusted code producer. The code producer delivers both a program and a formal proof that verifies that the code meets the desired safety policies. Safety policies generally express properties that prohibit the code from harmful behavior such as accessing private data, overwriting important data, accessing unauthorized resources, or consuming too many resources. Ideally, a proof is constructed automatically, and proof search may be directed using information that is passed on from the code producer's compiler. Proofs provided semi-automatically or interactively using a proof assistant are possible as well. Upon receiving the code and proof, the code consumer uses a mechanical proof checker to check the proof before executing the code. This special issue will be devoted to the topic of proof-carrying code and related approaches which use formal reasoning to enhance safety and reliability of software. Manuscripts emphasizing original results and study of tools and methods for proof generation, proof checking, and their integration with code generation/compilation are of particular interest. Manuscripts should be unpublished works and not submitted elsewhere. Revised and enhanced versions of papers published in conference proceedings that have not appeared in archival journals are eligible for submission. All submissions will be reviewed according to the usual standards of scholarship and originality. Information on JAR submissions can be found at URL http://www-unix.mcs.anl.gov/JAR/. Please format your submissions using JAR macros (available at http://www.wkap.nl/kaphtml.htm/STYLEFILES) Submissions should be sent to the guest editor in postscript format, preferably gzipped and uuencoded. In addition, please send as plain text, the title, authors, abstract, and contact information for the paper. The submission deadline is February 22, 2002. Guest Editor: Amy Felty, University of Ottawa, afelty(a)site.uottawa.ca This information is available on the web at: http://www.site.uottawa.ca/~afelty/jar-pcc/

1 0

hiding imports
by Iavor S. Diatchki 04 Dec '01

04 Dec '01

hello, i was wondering if there was a reasong why "hiding imports" have different semantics from "importing imports" and "exports". what i mean is, if one writes: module A(T) where data T = T only the type constructor T is exported. simillarly if i write: module A where data T = T module B where import A(T) only the type constructor is imported, but if i write (module A as above) module B where import A hiding (T) both the type constructor and the value constructor are hidden. this seems not only irregular, but may also be inconvinient in practise as sometimes it happens that a type constructor and a data constructor have the same name, but the data constructor does not "belong" to the type constructor. for example: module A where type T = TGen Int data TGen a = T a | S module B where import A hiding (T) -- intending to just hide the type T genF = T -- error T not in scope! so if i wanted to ignore the type T, but still have the data constructor i have to explicitly import it, i.e. write: module B where import A hiding (T) import A (TGen(T)) which is kind of ugly. is this strange behaviour for historical reasons, or was there a practical reason why this decision was made? bye iavor

1 0

Haskell 98 Revised
by Simon Peyton-Jones 04 Dec '01

04 Dec '01

Gentle Haskellers The December issue of the Haskell 98 Report is done. http://research.microsoft.com/~simonpj/haskell98-revised As usual, changes are highlighted in the overall bugs list thus: [Dec 2001], so you can find them easily. There are the usual crop of presentational improvements (thanks esp to Ian Lynagh, George Russel, Feliks Kluzniak for much careful reading). There are two non-trivial changes that I decided to adopt: 1. Add showIntAtBase, showOct and showHex to the Numeric library. 2. Remove the wart concerning qualified names in instance declarations. This a breaking change, in the sense that exotic Haskell programs may have to change, but I judge it worth it, after some consultation. In particular: * if you use H/Direct, you'll have to re-generate your Haskell files with a different flag * if you use the Edison library, you'll need a new copy of the library (this isn't a problem in practice because it comes bundled with your compiler) The other thing I'd ask you to look at particularly is the layout algorithm. George and Ian have both pointed out bugs, but it's very easy to get wrong so a few more eyeballs on it would be a Good Thing. The only unresolved thing I have in my pile is some stuff about the lexical syntax of comments, which I find it hard to get excited about. We are definitely converging. My earnest hope is to finally freeze the Report at Christmas. So this is your last chance. I hope. Thanks Simon ========================== The instance decl wart In Haskell 98 as she stands, when you give an instance declaration, the method name is treated as an *occurrence* and so has to be qualified if it is ambiguous: module Foo where compare = <something> instance Ord T where Prelude.compare = ... -- NB! You have to say "Prelude.compare" on the LHS, because both Prelude.compare and Foo.compare are in scope. This is reasonable on the RHS, of course, but it is plain silly on the LHS, because it *must* refer to the compare from the Ord class! After all, its an instance declaration for Ord. Not only is it surprising (most people think that plain "compare" should be fine) but it also adds a whole new big production to the grammar (qfunlhs). So, after some consulation, I have decided to remove this wierd thing. The analogy is with type signatures, where we can already write module Foo where compare :: Int -> Int compare = ... Note that we don't have to write "Foo.compare :: Int -> Int" in the type signature. The remaining question is how to explain this point in the Report. My initial conclusion is that simply deleting the offending text was enough. Explaining the problem (given that it isn't really a problem) seems to complicate matters. Nevertheless I'm entirely happy to add an explanation, if people want it and say what they'd like to see. The relevant section is 4.3.2. page 46 of the Report.

2 1

hallo
by biene2xxl＠mail.com 04 Dec '01

04 Dec '01

Mein Geheimnis ist, da� ich immer Lust auf Erotik habe. Bin ich eine Nymphomanin? Oder fehlt mir nur der richtige Partner/in? K�nntest Du das sein? Ja? Dann besuch mich doch mal auf meiner kleinen Homepage http://free.adult-freespace.de/coolgirl22/ cu bis bald Biene

1 0

PEPM'02 -- call for participation
by Peter Thiemann 03 Dec '01

03 Dec '01

CALL FOR PARTICIPATION 2002 ACM SIGPLAN Workshop on Partial Evaluation and Semantics-Based Program Manipulation (PEPM'02) Portland, Oregon, USA, January 14-15, 2002 (colocated with POPL'02) http://www.informatik.uni-freiburg.de/~thiemann/pepm02 The PEPM'02 workshop will bring together researchers working in the areas of semantics-based program manipulation, partial evaluation, and program generation. The workshop focuses on techniques, supporting theory, and applications of the analysis and manipulation of programs. PRELIMINARY PROGRAM Monday, 14 January 2002 BREAKFAST 8:45 WELCOME (chair: PT) 9:00 Invited Talk: Staged Compilation Craig Chambers (U Washington) 10:00 BREAK 10:30 Towards Bridging the Gap Between Programming Languages and Partial Evaluation Anne-Francoise Le Meur, Julia L. Lawall, Charles Consel (INRIA/LaBRI, France) 11:00 Online Partial Evaluation for Shift and Reset Kenichi Asai (Ochanomizu University, Japan) 11:30 Growing Languages with Metamorphic Syntax Macros Claus Brabrand, Michael I. Schwartzbach (BRICS, University of Aarhus, Denmark) 12:00 LUNCH 14:00 From Checking to Inference via Driving and Dag Grammars Jens Peter Secher and Morten Heine Sørensen (DIKU, Denmark) 14:30 Cost-Augmented Narrowing-Driven Specialization Germán Vidal (DSIC, Technical University of Valencia, Spain) 15:00 Path Dependent Analysis of Logic Programs Lunjin Lu (Oakland University, USA) 15:30 BREAK 16:00 Automatic Time-Bound Analysis for a Higher-Order Language Gustavo Gómez and Yanhong A. Liu (Indiana University, USA) 16:30 Compositionality in the Puzzle of Semantics Roberto Giacobazzi, Isabella Mastroeni (Dipartimento di Informatica, Universita' degli studi di Verona, Italy) 17:00 PC REPORT Tuesday, 15 January 2002 BREAKFAST 9:00 shared WITS-Session "Non-Interference and Probability" 10:30 BREAK 11:00 Invited Talk: Implementation of Automatic Differentiation Tools Christian Bischof (Technical University of Aachen, Germany), Paul Hovland, Boyana Norris (Argonne National Laboratory, USA), 12:00 LUNCH 14:00 Program Optimization Using Indexed and Recursive Data Structures Yanhong A. Liu and Scott D. Stoller (State University of New York at Stony Brook, USA) 14:30 Mixed-Initiative Interaction = Mixed Computation Naren Ramakrishnan, Robert Capra, Manuel Perez-Quinones (Department of Computer Science, Virginia Tech, USA) 15:00 CPS Translating Inductive and Coinductive Types Gilles Barthe (INRIA, France), Tarmo Uustalu (University of Minho, Portugal) 15:30 CLOSING

1 0

Mathematics of Program Construction, 2nd CFP
by mpc02 03 Dec '01

03 Dec '01

[Apologies for multiple copies] MPC 2002 6th International Conference on MATHEMATICS OF PROGRAM CONSTRUCTION ----------------------------------- http://www.cs.ukc.ac.uk/conf/mpc2002/ Organised in conjunction with WCGP '02 8--10 July, 2002 Dagstuhl, Germany INVITED SPEAKERS include: Robert Giegerich Dexter Kozen CALL FOR PAPERS This conference aims to promote the development of mathematical principles and techniques that are demonstrably useful and usable in the process of constructing computer programs (whether implemented in hardware or software). The focus of the conference is on techniques that combine precision with conciseness, enabling programs to be constructed by formal calculation. Within this theme, the scope of the conference is very diverse. We welcome contributions to programming methodology (for example, formal methods for program specification and transformation), to programming paradigms (for example, generic programming techniques and type systems) and to language design (for example, programming calculi and programming language semantics). Theoretical contributions are welcome provided their relevance to program construction is evident; discussion of applications is welcome provided the mathematical basis is evident. The conference will be organised in conjunction with the IFIP TC2 Working Conference on Generic Programming, WCGP '02. There will also be a number of co-located workshops, including CMPP. IMPORTANT DATES Deadline for submission of papers: 6th January, 2002 Notification of acceptance/rejection: 4th March, 2002 Final papers due: 25th April, 2002 Full papers should be submitted in Postscript or pdf format by e-mail to mpc02(a)ukc.ac.uk by 6th January, 2002. PROGRAMME COMMITTEE Roland Backhouse (UK) Eerke Boiten (UK, co-chair) Michael Butler (UK) Ernie Cohen (USA) Jules Desharnais (Canada) Jeremy Gibbons (UK, GP liaison) David Gries (USA) Lindsay Groves (New Zealand) Ian Hayes (Australia) Eric Hehner (Canada) Zhenjiang Hu (Japan) John Hughes (Sweden) Bart Jacobs (The Netherlands) Johan Jeuring (The Netherlands, GP liaison) Dick Kieburtz (USA) Dexter Kozen (USA) K. Rustan M. Leino (USA) Christian Lengauer (Germany, CMPP liaison) Erik Meijer (The Netherlands/USA) Bernhard Moeller (Germany, co-chair) David Naumann (USA) J.N. Oliveira (Portugal) Alberto Pardo (Uruguay) Peter Pepper (Germany) Kaisa Sere (Finland) Mark Utting (New Zealand) FURTHER INFORMATION Please refer to the web page for further details. http://www.cs.ukc.ac.uk/conf/mpc2002/ -- Mathematics of Program Construction '02 at Dagstuhl Eerke Boiten, Computing Laboratory, University of Kent at Canterbury, UK +44.1227.827615 (fax 762811)

1 0

��Цʱ�� 12-3
by vcomic＠speed.sender.com 03 Dec '01

03 Dec '01

1 0

Lazy Sound File IO
by Carl McTague 02 Dec '01

02 Dec '01

Please let me refine my question. Is there a general way to coerce an [Int] or [Double] etc. into a String, so that it may be written out to a binary file with hPutStr? There is toEnum, but this doesn't seem like a real solution, since it only works for Int values <256. Thanks, Carl

2 1