- Haskell - Haskell.org

Re: Instance declarations and class exports
by Malcolm Wallace 11 Dec '01

11 Dec '01

> I therefore want to propose: > > 1. "subordinate" names in export lists are always unqualified > Thus, we can have M.Ix( index ), but not M.Ix( T.index ). I don't see a compelling reason to outlaw the latter. We can permit the subordinate name to be unqualified, but why should we enforce it? Ditto for method names in instance decls. > I'd like to find a better wording for (2): > > 2. A subordinate name in an export list is legal if the entity (class > operation or data constructor) is in scope in the module, regardless > of whether it is in scope under a qualified or unqualified name. > (In the example, T.index.) Suggestion: A method name, constructor, or field name is permitted to be used unqualified in a subordinate position of an export list, iff the entity it refers to is in scope in the module, regardless of whether the name must be used qualified elsewhere in the module. There is a distinction between a subordinate name (e.g. the index method of Ix), and its use in a subordinate position (e.g. in Ix(index)). In the example, it would be perfectly legal to say module Foo( T.index ) where import qualified Ix as M( Ix ) import qualified Ix as T( index ) index v = ... -- A local declaration where the method name (but not its class) is re-exported. Regards, Malcolm

1 0

Instance declarations and class exports
by Simon Peyton-Jones 11 Dec '01

11 Dec '01

Folks, Iavor has made two excellent points, upon which I have been ruminating (and consulting). Consider module Foo( M.Ix( index ) ) where import qualified Ix as M( Ix ) import qualified Ix as T( index ) instance M.Ix MyType where index a = ... index v = ... -- A local declaration Notice that: * The Ix class is in scope as "M.Ix", but its index method is in scope ias "T.index". * Nevertheless, it's 100% clear what we mean in the instance declaration * It's also 100% clear what we mean in the export list M.Ix( index ) (The report is currently silent about whether this is legal.) * These two situations are very similar, and should be resolved in the same way * I think we all agree that it woudl be illegal to mention the 'range' method of the Ix class, either in the instance cecl, or in theexport list. Why? Because 'range' is not imported. I therefore want to propose: 1. "subordinate" names in export lists are always unqualified Thus, we can have M.Ix( index ), but not M.Ix( T.index ). 2. A subordinate name in an export list is legal if the entity (class operation or data constructor) is in scope in the module, regardless of whether it is in scope under a qualified or unqualified name. (In the example, T.index.) 3. The exact same rule is used to determine whether the class method name on the LHS of an instance-decl binding is legal. This time I have implemented the rule first, and it seems fine. These are basically clarifications. Objections? Comments? I'd like to find a better wording for (2) above. Simon

1 0

FW: Clarification of \begin{code} ... \end{code} stuff
by Simon Peyton-Jones 11 Dec '01

11 Dec '01

> In the thread "Literate scripts not handled correctly" Simon Marlow > said: > > > Yes, it looks like GHC's unlit program removes whitespace when > > looking for \begin{code}, but not for \end{code}. The report isn't > > explicit about whether whitespace is allowed on these lines, but I > > would tend to the view that it isn't. > > Can you please clarify this in the report [...] I'm sure the "\begin{code}" and "\end{code}" should be at the beginning of a line. Whether anything else should be allowed on that line is moot. Maybe not. What would the layout be for this? \begin{code} f x = x \end{code} On the other hand it would be painful if a block of code was omitted because of a trailing space on the \begin{code} line; an easy error. I therefore propose code starts on the line *following* a line beginning with \begin{code}. And similarly stops on a line beginning \end{code}. For Ian's snippet: \begin{code} foo = "hello\ \end{code}" \end{code} I think it's clear that the first \end{code} should be scanned as part of the string literal. Simon

1 0

Re: Clarification of \begin{code} ... \end{code} stuff
by Ian Lynagh 10 Dec '01

10 Dec '01

On Mon, Dec 10, 2001 at 04:03:27PM +0000, Ian Lynagh wrote: > > In the thread "Literate scripts not handled correctly" Simon Marlow > said: > > > Yes, it looks like GHC's unlit program removes whitespace when looking > > for \begin{code}, but not for \end{code}. The report isn't explicit > > about whether whitespace is allowed on these lines, but I would tend to > > the view that it isn't. > > Can you please clarify this in the report [...] Here's an interesting snippet: \begin{code} foo = "hello\ \end{code}" \end{code} which nhc and hugs accept, GHC says "error in character literal". I think this is a good reason for at least non-whitespace to not be allowed on the \begin{code} and \end{code} lines (or rather, for lines with other non-whitespace on them not to be treated as such). Thanks Ian

1 0

RE: Another question about sharing
by Simon Marlow 10 Dec '01

10 Dec '01

> Well, how about the following little circular program? > > paths :: () -> [Path] > paths () = let r = T : branch r in r > > As far as I can understand what you are looking for, I think > this meets > the bill. Every use of the expression `paths ()' will re-evaluate > the infinite structure to the extent its context requires it, and the > expanded value will be thrown away as soon as the value of this > instance of `paths ()' is no longer required. You can't rely on adding dummy arguments to cause re-evaluation: full-laziness (enabled when optimisation is on in GHC) will do the opposite transformation. Cheers, Simon

2 1

RE: Another question about sharing
by Simon Marlow 10 Dec '01

10 Dec '01

> If I have.. > data Path = L Path | R Path | T > paths = T : branch paths > branch (p:ps) = L p : R p : branch ps > > This will be a CAF which can never be garbage collected, but > may grow indefinitely large as it gets reduced. Correct? GHC will collect the CAF when it can determine that it is no longer required. In GHCi, the CAF will only be collected if you turn on ':set +r', otherwise evaluated CAFs are retained between evaluations. Cheers, Simon

3 2

RE: Another question about sharing
by Simon Marlow 10 Dec '01

10 Dec '01

> I'm curious, how does GHC determine that the CAF is no longer required > if it is referenced by code (somehow)? If code was also some kind of > heap allocated data structure I guess this would be possible, but I > thought this wasn't so with GHC. GHC actually tracks references to top-level entities from code, so that the GC can trace the transitive closure of live code and hence find all the reachable CAFs. It's a real pain, but worth it. > But in any case, I'm not sure this really helps me. I don't really > mind if the unreduced form of the CAF is garbage collected or not > (it's only going to be a few words of memory). The effect I'm trying > to get is to ensure that the (partially) reduced form of the CAF only > lives as long as any (non code) heap object which references it. > Does that make sense? (probably not:-) If I understand correctly, that's the behaviour you'll get with GHC, and (I think) nhc98. Cheers, Simon

1 0

WAAAPL 2002, preliminary announcement
by Ralf Hinze 10 Dec '01

10 Dec '01

Apologies if you receive multiple copies... ============================================================================ PRELIMINARY CALL FOR PAPERS [Deadline for submission: 3rd June 2002] WAAAPL 2002 Workshop on Algorithmic Aspects of Advanced Programming Languages Part of PLI'02 (approval pending) Pittsburgh, PA, USA date to be announced (probably Oct 7 or Oct 8, 2002) http://www.cs.uni-bonn.de/~ralf/waaapl02.{html,pdf,ps,dvi,txt} ============================================================================ Scope ----- WAAAPL (pronounced "wapple") seeks papers on all aspects of the design, analysis, evaluation, or synthesis of algorithms or data structures in the context of advanced programming languages, such as functional or logic languages, where traditional algorithms or data structures may be awkward or impossible to apply. Possible topics include (but are not limited to): o new algorithms or data structures, o empirical studies of existing algorithms or data structures, o new techniques or frameworks for the design, analysis, evaluation, or synthesis of algorithms or data structures, o applications or case studies, o pedagogical issues (language aspects of teaching algorithms or algorithmic aspects of teaching languages). A previous WAAAPL workshop has been held in Paris (1999). Submission details ------------------ Deadline for submission: 3rd June 2002 Notification of acceptance: 1st July 2002 Final submission due: 1st August 2002 WAAAPL Workshop: to be announced (probably Oct 7 or Oct 8, 2002) Authors should submit papers of at most 12 pages, in postscript format, formatted for A4 paper, to Ralf Hinze (ralf(a)cs.uni-bonn.de) or Chris Okasaki (Christopher.Okasaki(a)usma.edu) by 3rd June 2002. The accepted papers will be published as a University of Bonn technical report. Programme committee ------------------- Richard Bird Oxford University Michael Hanus University of Kiel Ralf Hinze University of Bonn (co-chair) Zhenjiang Hu University of Tokyo Haim Kaplan Tel Aviv University Chris Okasaki United States Military Academy (co-chair) Melissa O'Neill Harvey Mudd College ============================================================================

1 0

Another question about sharing
by Adrian Hey 10 Dec '01

10 Dec '01

Hello, If I have.. data Path = L Path | R Path | T paths = T : branch paths branch (p:ps) = L p : R p : branch ps This will be a CAF which can never be garbage collected, but may grow indefinitely large as it gets reduced. Correct? Is it possible to avoid this problem somehow? What I have in mind is a special thunk which get's copied (as a normal thunk) before it gets reduced. Pointer references are preserved during copying, except self referential pointers, which are updated to point to the new thunk. Alternatively.. I had thought maybe a function with a dummy argument like this would do.. paths x = let paths' = T : branch paths' in paths' But the paths' will just be lambda lifted as a CAF (I believe) This seems to solve the lambda lifting problem.. paths x = T : branch (paths x) but I'm not sure how compilers will treat this. I think I'll also loose the sharing of earilier paths in new paths, unless the compiler optimises the self reference. If I redefined my datatype.. data Path x = L (Path x) | R (Path x) | T x I could then use the function with dummy argument solution.. paths x = let paths' = T x : branch paths' in paths' This seems to solve both problems, but there's yet another problem I anticipate.. When using any of these dummy argument solutions I have to make sure the argument is not a constant (or I'm back to the lambda lifting problem again). So it has to be any handy unknown variable (argument)? This presents the problem that the unknown variable may itself be quite large, and have it's lifetime unduly prolonged because it's now referenced by many paths. Any advice? Thanks -- Adrian Hey

2 1

FME 2002: 2nd call for papers
by mailinglist-admin＠fmeurope.org 10 Dec '01

10 Dec '01

apologies if you receive multiple copies... FORMAL METHODS EUROPE FME 2002 "Formal Methods: Getting IT Right" International Symposium and Tutorials http://floc02.diku.dk/FME/ 20-24 July 2002 Second Call for Papers ********************** FME 2002 is the eleventh in a series of symposia organised by Formal Methods Europe, an independent association whose aim is to stimulate the use of, and research on, formal methods for software development. These symposia have been notably successful in bringing together a community of users, researchers, and developers of precise mathematical methods for software development. In 2002 the symposium will be held in conjunction with the third Federated Logic Conference (FLoC'02) in Copenhagen, Denmark. The theme of FME 2002 is Formal Methods: Getting IT Right. The double meaning is intentional. On the one hand, the theme acknowledges the significant contribution formal methods can make to Information Technology, by enabling computer systems to be described precisely and reasoned about with rigour. On the other hand, it recognises that current formal methods are not perfect, and further research and practice are required to improve their foundations, applicability and effectiveness. FME seeks papers in all aspects of formal methods for computer systems, including the following: * theoretical foundations * practical use and case studies * specification and modelling techniques * software development and refinement * tool support and software engineering environments for formal methods * verification and validation * hidden formal methods, and making benefits available to non-experts * reusable domain theories * method integration * hardware verification In addition to presentations of submitted papers, the symposium will offer tutorials, workshops, invited speakers, and tool demonstrations. PAPERS Full papers should be submitted in Postscript or PDF format by e-mail to reach the Program Co-chairs by 15 January 2002. Papers will be refereed by the Program Committee and must be original research papers that have not been submitted elsewhere for publication. Accepted papers will be published in the symposium proceedings. Papers should not exceed twenty pages, although longer papers will be considered if their content justifies it. LNCS format should be used: see http://www.springer.de/comp/lncs/authors.html for details. Please include a short list of keywords on a separate line at the end of the abstract, beginning with the word "Keyword:" in boldface. OTHER SYMPOSIUM ACTIVITIES Tutorials and workshops will be held on 20-21 July 2002. Each tutorial will last one-half or one day. Proposals are welcome, and should be directed to the Program Co-chairs by 15 January 2002; more details will appear on the web-site above. Tool demonstrations will also take place during the symposium, with the opportunity for presentations to be made about each tool. Proposals for tool demonstrations should be made to the Tool Demonstration Coordinator, with whom provison of necessary computing facilities should be discussed. PEOPLE Organising Chair Dines Bjørner Informatics and Mathematical Modelling Building 322, Richard Petersens Plads Technical University of Denmark DK-2800 Lyngby, Denmark Tel: +45 4525 3720 Email: db(a)imm.dtu.dk Programme Co-chairs Lars-Henrik Eriksson, Industrilogik L4i AB Box 6205, SE-102 34 Stockholm, Sweden Tel: +46 8 670 37 10 Fax: +46 8 32 12 82 Email: lhe(a)L4i.se Peter Lindsay, Software Verification Research Centre The University of Queensland, Queensland 4072, Australia Tel: +61 7 3365 2005 Fax: +61 7 3365 1533 Email: Peter.Lindsay(a)svrc.uq.edu.au Programme Committee Bernhard Aichernig Graz University of Technology, Austria Juan Bicarregui Rutherford Appleton Laboratory, UK Ernie Cohen Telcordia Technologies, USA Ben Di Vito NASA Langley Research Center, USA Cindy Eisner IBM Haifa Research Laboratory, Israel Lars-Henrik Eriksson (co-chair) Industrilogik, Sweden John Fitzgerald Transitive Technologies Ltd, UK Jim Grundy Intel Corporation, USA Yves Ledru LSR/IMAG, France Peter Lindsay (co-chair) University of Queensland, Australia Markus Montigel University of New Orleans, USA Richard Moore IFAD, Denmark Tobias Nipkow Technische Universität München, Germany Colin O'Halloran Qinetiq (ex-DERA), UK Jose Oliveira Universidade do Minho, Portugal Nico Plat West Consulting, The Netherlands Jeannette Wing Carnegie Mellon University, USA Jim Woodcock Oxford University, UK Joakim von Wright Åbo Akademi University, Finland Pamela Zave AT&T Laboratories, USA Tool Demonstration Coordinator Paul Mukherjee The Institute of Applied Computer Sciense (IFAD) Forskerparken 10, DK-5230 Odense M, Denmark Tel: +45 6315 7131 Fax: +45 6593 2999 Email: paul.mukherjee(a)ifad.dk IMPORTANT DATES Submission of papers, tutorial proposals and workshop proposals: 15 January 2002 Notification of acceptance/rejection: 27 March 2002 Camera ready final version of papers due: 10 May 2002 l _______________________________________________ Mailinglist mailing list Mailinglist(a)fmeurope.org http://www.fmeurope.org/mailman/listinfo/mailinglist

1 0