- Haskell - Haskell.org

RE: Module re-exportation weekend puzzler
by Simon Peyton-Jones 06 Nov '02

06 Nov '02

Thomas, Iavor, Thanks for your message. | Are you saying that you think the report doesn't fully define the | meaning of the module system, or just that difficult to understand and | needs to be clarified? The former, and hence it ought to be clarified. But after contemplating your message, your fine formal specification, and then looking at the Report again, I conclude that my proposed fix was wrong. (I elaborate below.) The current wording is this: | The form "module M" names the set of all entities whose | unqualified name, e, is in scope, and for which the qualified | name M.e is also in scope and refers to the same entity as e. What is un-clear about this is the phrase "...for which the qualified name M.e is also in scope and refers to e". Unclear because it could be read as saying EITHER: that M.e can refer unambiguously only to this one entity, OR: that e is in scope under the name M.e (but M.e could be ambiguous) Either would make sense, but the latter is both more symmetrical (see Cambridge1 vs Cambridge2 below) and matches your formal spec (from which we should not lightly deviate). So I am happy to adopt your interpretation, but I'd like to clarify the wording. Here's an alternative sentence: The form "module M" names the set of all entities that are in scope with both an unqualified name 'e' and a qualified name 'M.e'. Would that be better? Can you suggest anything else? Simo If anyone else is interested, I'll elaborate Thomas and Iavor's example slightly: | module Cambridge1(module Simon) where | import PJ as Simon | import qualified Marlow as Simon | | module Cambridge2(module Simon) where | import PJ as Simon | import Marlow | | module Cambridge3(module Simon) where | import PJ as Simon | import Marlow as Simon | | module Marlow where | simon = "Simon Marlow" | | module PJ where | simon = "Simon PJ" So in Cambridge1 'simon' is unambiguous 'Simon.simon' is ambiguous But in Cambridge2 'simon' is ambiguous 'Simon.simon' is unambiguous In Cambridge 3 both are ambiguous The spec as it stands says that the export item 'module M' identifies those items x that are in scope both as 'x' and as 'M.x'. In both Cambridge1 and Cambridge2, there is only one such entity, so both are legal. (The fix I proposed yesterday would render Cambridge1 illegal.) In Cambridge3, the rule would specify that both entities "simon from module PJ" and "simon from module Marlow" are identified by 'module Simon'. And that is illegal because of the last clause of 5.2 specifies that one cannot export two entities with the same unqualified name.

2 1

FM03 Call for Papers - Preliminary
by mailinglist-admin＠fmeurope.org 06 Nov '02

06 Nov '02

CALL FOR PAPERS FM 2003 The 12th International FME Symposium Pisa, Italy - September 8-14, 2003 http://fme03.isti.cnr.it FM 2003 is the twelfth in a series of symposia organized 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 as well as industrial users. Formal methods have been controversial throughout their history, and the realization of their full potential remains, in the eyes of many practitioners, merely a promise. Have they been successful in industry? If so, under which conditions? Has any progress been made in dispelling the skepticism that surrounds them? Are they worth the effort? Which aspects of formal methods have become so well established in the industrial practices to loose the "formal method" label in the meanwhile? FM 2003 aims to answer these questions, by seeking contributions not only from the Formal Methods community but also from outsiders and even from skeptical people who are most welcome to explain, document, and motivate the source of their reluctance. We are confident that a wide spectrum of experiences and a loyal contrasting of opinions will foster a better and deeper understanding, if not a wider adoption of Formal Methods. Far from restricting the focus of the conference, however, FM 2003 also welcomes papers with strong theoretical content that establish a connection with the practice of formal methods. Therefore, FM 2003 welcomes papers in all aspects of formal methods for computer systems, including the following: -introducing formal methods in the practice of industrial processes (technical, organizational, social, psychological aspects) - concerns and risks for potential adopters of formal methods; cost-benefit analysis - reports on practical use and case studies (reporting positive or negative experiences) - formal methods in hardware and system design - reusable domain theories - theoretical foundations (specification and modeling, refining, verification, etc.) - tool support and software engineering - environments for formal methods - method integration Papers Full papers should be submitted electronically via the Web by March 7, 2003. Full submission details will be published on the conference web site. Papers will be evaluated by the Program Committee according to their originality, significance, soundness, quality of presentation and relevance with respect to the main issues of the symposium. Papers should have not been submitted elsewhere for publication. Accepted papers will be published in the symposium proceedings in the LNCS series by Springer Verlag. Papers should not exceed twenty pages, although longer papers will be considered if their content justifies it. LNCS format should be used. Please include a short list of keywords on a separate line at the end of the abstract, beginning with the word "Keywords:" in boldface. Other symposium activities In addition to presentations of submitted papers, the symposium will offer half-day or full-day tutorials, one-day or two-days workshops, invited speakers, and tool demonstrations with presentations. Please send your proposals for tutorials/workshops/tool exhibitions to the related chairs by the deadlines indicated below. For full details of what is required, whom to contact, etc, see the web site http://fme03.isti.cnr.it, or send your query to fme03(a)isti.cnr.it. Submission Deadlines March 7, 2003: Papers (firm deadline) March 7, 2003: Workshop/tutorial proposals May 9, 2003: Tool Exhibition proposals June 8, 2003: Papers' final version Acceptance Notifications March 20, 2003: Tutorials/workshops May 9, 2003: Papers June 8, 2003: Tool Exhibition =========================================================================== Stefania Gnesi IEI-CNR tel: +39 050 3152918 Area della Ricerca CNR mobile: +39 348 8283128 VIA G. MORUZZI, 1 fax: +39 050 3152810 I-56124 PISA (Italy) e-mail: gnesi(a)iei.pi.cnr.it http://matrix.iei.pi.cnr.it/FMT/ http://rep1.iei.pi.cnr.it/~gnesi/ =========================================================================== _______________________________________________ Mailinglist mailing list Mailinglist(a)fmeurope.org http://www.fmeurope.org/mailman/listinfo/mailinglist

1 0

RE: Module re-exportation weekend puzzler
by Simon Marlow 06 Nov '02

06 Nov '02

> The meaning of "module M" in export lists is rather subtle, and the > above reformulation (or the one-word change) seems to make a subtle > change to it. It is not just a clarification. Is that what > you intend?! It depends, I guess, on your interpretation of the report as it stands. It wasn't clear to me whether it is legal to export an entity, using the 'module M' syntax, whose qualified name is ambiguous. Admittedly, if I'd checked your specification I'd have noticed that your interpretation differed from mine, sorry about that. Nevertheless, since there are two interpretations, the report should clarify which one is meant. > A nice aspect of our formal semantics is that the computation of the > exports and inscope relations, which includes fixpoint > iteration to give > meaning to recursive modules, and the error checking can be kept > separate. The change proposed above means that the error > checking has to > be integrated with the fixpoint iteration (or that the fixpoint > iteration has to return more than the resulting inscope/export > relations), and thus complicates the specification. Ok, that sounds like a good reason to prefer your current interpretation. Cheers, Simon

1 0

RTA'03: call for papers
by Femke van Raamsdonk 06 Nov '02

06 Nov '02

The call for papers for RTA'03 might be relevant for the readers of the Haskell lists since papers on applications of rewriting are explicitly invited. ******************************************* ****************************** * * * RTA'03 CALL FOR PAPERS * * * ****************************** http://www.dsic.upv.es/~rdp03/rta The 14th International Conference on Rewriting Techniques and Applications (RTA'03) will be part of the Federated Conference on Rewriting Deduction and Programming (RDP'03). IMPORTANT DATES: * January 15 2003 electronic submission of title + abstract * January 22 2003 electronic submission of papers * March 15 2003 notification of acceptance * April 7 2003 final version of accepted papers * June 9-11 2003 RTA'03 * June 8-14 2003 RPD'03 RTA is the major forum for the presentation of research on all aspects of rewriting. Typical areas of interest include (but are not limited to): * APPLICATIONS: case studies; (rule-based) programming; symbolic and algebraic computation; theorem proving; system synthesis and verification; proof checking. * FOUNDATIONS: matching and unification; completion techniques; strategies; constraint solving; explicit substitutions. * FRAMEWORKS: string, term, and graph rewriting; lambda-calculus and higher-order rewriting; proof nets; constrained rewriting/deduction; categorical and infinitary rewriting. * IMPLEMENTATION: compilation techniques; parallel execution; rewriting tools. * SEMANTICS: equational logic; rewriting logic. RTA'03 PROGRAM COMMITEE: Harald Ganzinger (Max-Planck-Institut) Claude Kirchner (Nancy) Salvador Lucas (Valencia) (Conference Chair) Chris Lynch (Clarkson) Jose Meseguer (Urbana) Robert Nieuwenhuis (Barcelona) (Program Chair) Tobias Nipkow (Munich) Vincent van Oostrom (Utrecht) Christine Paulin (Paris-sud) Frank Pfenning (Carnegie Mellon) Mario Rodriguez-Artalejo (Madrid) Sophie Tison (Lille) Ashish Tiwari (SRI) Andrei Voronkov (Manchester) Hantao Zhang (Iowa) RTA'03 SUBMISSIONS: Submissions must be original and not submitted for publication elsewhere. Submission categories include regular research papers and system descriptions. Also problem sets and submissions decribing interesting applications of rewriting techniques will be very welcome. As usual, accepted papers will appear in the Springer-Verlag Lecture Notes series. More information about paper submission will be available at the RDP'03 web page http://www.dsic.upv.es/~rdp03/

1 0

RE: Module re-exportation weekend puzzler
by Simon Peyton-Jones 06 Nov '02

06 Nov '02

Folks Another minor H98 glitch. Consider this: | > > module D (module Char) where | > > { import qualified Char; import List as Char } | > | > Everything in List, nothing from Char. | | Interesting... what happens when List and Char overlap here? Suppose | there exists entities List.f and Char.f, then it would be an error to | refer to Char.f in the body of the module. On export lists, the report | says: | | The form "module M" names the set of all entities whose | unqualified name, e, is in scope, and for which the qualified | name M.e is also in scope and refers to the same entity as e. | | Perhaps this could be clarified by insertion of the word "unambiguously" | before "refers to the same entity as e". It's not essential, but it | would make the expected behaviour in this case clearer. I agree with this. (Actually GHC gets it wrong right now.) Another way to say it is this: The export item 'module M' exports all entities e such that a) The qualified name M.e is unambiguous and refers to that entity b) The unqualified name e is in scope, perhaps ambiguously, and at least one of its bindings refers to that entity I'll make the one-word change in the Report that Simon suggests, though. Simon

3 2

RE: getting the right types
by Simon Peyton-Jones 05 Nov '02

05 Nov '02

Interesting. You want to control a data type used *inside* an algorithm from outside. Here's a smaller version: foo :: String -> String foo s = show (read s) This is ambiguous; what type should 'read' return? Your idea: pass in that type via a proxy value: foo :: (Read a, Show a) => a -> String -> String foo p s = show (read s `asTypeOf` p) Now you can say foo (undefined :: Int) "34" and it'll work. A neater way to do this with GHC is to use scoped type variables: foo :: (Read a, Show a) => a -> String -> String foo (p::a) s = show (read s :: a) One reason this is neater is that it scales up better when you want to pass a type constructor instead of a type. First define a data type with no constructors, and a phantom type arg data Proxy (a :: * -> *) Now you can write a function like this f :: (MArray a ix e) => Proxy a -> .... f (p :: Proxy a) ... = do { (arr :: a ix e) <- newArray ... The type variable 'a' is bound by the (Proxy a) pattern, and scopes over the body. The type variables 'ix' and 'e' in the do-binding are bound right there (since they aren't already in scope). Another use for phantom types! Simon | -----Original Message----- | From: Hal Daume III [mailto:hdaume@ISI.EDU] | Sent: 03 November 2002 19:31 | To: Haskell Mailing List | Subject: getting the right types | | Hi all, | | I have a function which essentially looks like this: | | f my_data = do | a1 <- newArray ... | ... | a2 <- newArray ... | g my_data a1 a2 | | where f is a monadic operation essentially of type 'a -> m a'. The | problem is that when this function isn't given a type signature, you get | something like: | | f :: (MArray a1 p e, MArray a2 p e) => t | | where a1 and a2 aren't bound in t. Now, I could provide a type signature | on the array expressions, something like: | | ... (a1 :: IOArray Int Int) <- newArray ... | | but i would like to be able to use unboxed arrays when possible, and i | don't want to bind the funtion to be in IO. My current solution is to | define: | | data ArrayType arr prob = forall ix . ArrayType (arr ix prob) | asArray :: arr ix prob -> ArrayType arr prob -> arr ix prob | a `asArray` _ = a | | Sort of like asTypeOf. Then, I change f to: | | f :: (MArray arr p e) => ArrayType arr p -> t -> m t | f arr_type ... = ... | | And inside f I have a function: | | newArray_arr bnds init = | do a <- newArray bnds init | return (a `asArray` arr_type) | | This enables me to create arrays of arbitrary representation with the same | values but different indices (which is important). | | However, this strikes me as horribly hackish. Is there some better way to | do this? | | - Hal | | -- | Hal Daume III | | "Computer science is no more about computers | hdaume(a)isi.edu | than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume | | _______________________________________________ | Haskell mailing list | Haskell(a)haskell.org | http://www.haskell.org/mailman/listinfo/haskell

1 0

RE: problems with ghc ffi
by Simon Peyton-Jones 04 Nov '02

04 Nov '02

GHC questions to ghc-users please, not the main Haskell list. You need the -ffi flag to use the FFI. S -----Original Message----- From: David Abbs [mailto:u0da2@dcs.shef.ac.uk] Sent: 04 November 2002 14:38 To: haskell(a)haskell.org Subject: problems with ghc ffi I am having problems with the GHC FFI, I am using GHC version 5.04.1 and am trying to compile the sample code given on the web site _______________________________________ module Foo where foreign export ccall foo :: Int -> IO Int foo :: Int -> IO Int foo n = return (length (f n)) f :: Int -> [Int] f 0 = [] f n = n:(f (n-1)) _____________________________________ when I enter c:/ghc M.hs to compile the code I get the following error M.hs:5: Type signature given for an expression I have tried compiling the code using GHC 5.04.1 on windows 98, XP and on Linux any help on would be greatly appreciated. _____________________________________________ David Abbs 3rd year Undergraduate in Computer Science at the University Of Sheffield _____________________________________________ u0da2(a)dcs.shef.ac.uk Have a very nice day !!

1 0

problems with ghc ffi
by David Abbs 04 Nov '02

04 Nov '02

I am having problems with the GHC FFI, I am using GHC version 5.04.1 and am trying to compile the sample code given on the web site _______________________________________ module Foo where foreign export ccall foo :: Int -> IO Int foo :: Int -> IO Int foo n = return (length (f n)) f :: Int -> [Int] f 0 = [] f n = n:(f (n-1)) _____________________________________ when I enter c:/ghc M.hs to compile the code I get the following error M.hs:5: Type signature given for an expression I have tried compiling the code using GHC 5.04.1 on windows 98, XP and on Linux any help on would be greatly appreciated. _____________________________________________David Abbs 3rd year Undergraduate in Computer Science at the University Of Sheffield_____________________________________________u0da2(a)dcs.shef.ac.uk Have a very nice day !!

1 0

getting the right types
by Hal Daume III 03 Nov '02

03 Nov '02

Hi all, I have a function which essentially looks like this: f my_data = do a1 <- newArray ... ... a2 <- newArray ... g my_data a1 a2 where f is a monadic operation essentially of type 'a -> m a'. The problem is that when this function isn't given a type signature, you get something like: f :: (MArray a1 p e, MArray a2 p e) => t where a1 and a2 aren't bound in t. Now, I could provide a type signature on the array expressions, something like: ... (a1 :: IOArray Int Int) <- newArray ... but i would like to be able to use unboxed arrays when possible, and i don't want to bind the funtion to be in IO. My current solution is to define: data ArrayType arr prob = forall ix . ArrayType (arr ix prob) asArray :: arr ix prob -> ArrayType arr prob -> arr ix prob a `asArray` _ = a Sort of like asTypeOf. Then, I change f to: f :: (MArray arr p e) => ArrayType arr p -> t -> m t f arr_type ... = ... And inside f I have a function: newArray_arr bnds init = do a <- newArray bnds init return (a `asArray` arr_type) This enables me to create arrays of arbitrary representation with the same values but different indices (which is important). However, this strikes me as horribly hackish. Is there some better way to do this? - Hal -- Hal Daume III "Computer science is no more about computers | hdaume(a)isi.edu than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume

1 0

EACL2003 Workshop CfP: 9th European Workshop on Natural Language Generation
by steven.krauwer＠elsnet.org 02 Nov '02

02 Nov '02

[ NB: the message you just received on the same subject contained the general CfP rather than the one for this workshop -- we apologize! ] Call for Papers 9th EUROPEAN WORKSHOP ON NATURAL LANGUAGE GENERATION (in conjunction with EACL2003) 13-14 April 2003 Budapest, Hungary (http://www.ags.uni-sb.de/~horacek/EACL-EWNLG03.html) Natural language generation (NLG) is a subfield of natural language processing that focuses on the generation of written texts in English or other human languages, generally from some non-linguistic data or knowledge. Accomplishing this goal may be envisioned for a number of different purposes, including standardized and/or multi-lingual reports, summaries, machine translation, dialog applications, and embedding in multi-media and hypertext environments. Consequently, the automated production of language is associated with a large number of highly diverse tasks whose appropriate orchestration in high quality poses a variety of theoretical and practical problems. Relevant issues include content selection, text organization, the production of referring expressions, aggregation, lexicalization, and surface realization, as well as coordination with other media. This workshop is part of a biennial series of workshops about natural language generation that has been running since 1987. Previous European workshops have been held at Royaumont, Edinburgh, Judenstein, Pisa, Leiden, Duisburg, and Toulouse. The goal of the workshop is to be an informal meeting which facilitates the dissemination of knowledge and expertise in the field. A substantial amount of time will be devoted to discussions, either in sequence or in parallel, depending on the number of participants. The workshop will focus on the following topics: - Formal semantics and NLG In several subareas of NLG (generation of referring expressions, lexicalization, among others) methods of formal semantics have already been used successfully. By focusing on this topic, we hope to strengthen the theoretical basis of NLG, complementing the application-oriented emphasis that has become dominant recently. - Evaluation of NLG systems Evaluation is an important factor for all NL systems, which is notoriously underrepresented in the generation field. By focusing on this topic, we hope to strengthen the empirical basis of NLG, preparing the ground for dedicated activities on this topic. We are considering organizing an invited talk on the first and a panel on the second topic. Substantial and original submissions on all subfields of NLG, especially on the two special topics, are welcome. Accepted papers will be scheduled for presentation. Since this is a workshop, we encourage papers that describe speculative ideas, work in progress, and discussions of important issues. WORKSHOP CHAIRS Ehud Reiter, Univ. of Aberdeen Helmut Horacek, Univ. of the Saarland Kees van Deemter, Univ. of Brighton PROGRAMME COMMITTEE John Bateman, Univ. of Bremen, Germany Nadjet Bouayad-Agha, Univ. Pompeu Fabra, Spain Stephan Busemann, DFKI, Germany Jo Calder, Fourth Person LtD, UK Charles Callaway, IRST, Italy John Carroll, Univ. of Sussex, UK Robert Dale, Macquarie University, Australia Claire Gardent, CNRS Nancy, France Pamela Jordan, Univ. of Pittsburgh, USA Rodger Kibble, Univ. of London, UK Emiel Krahmer, Univ. of Tilburg, The Netherlands Chris Mellish, Univ. of Edinburgh, UK Owen Rambow, Columbia Univ., USA Leo Wanner, Univ. of Stuttgart, Germany SUBMISSIONS Papers describing original work in all areas of NLG, in particular related to the workshop focus topics above, should be submitted electronically. Papers should be 4-8 pages long in PDF format following the guidelines at the EACL site (http://ufal.ms.mff.cuni.cz/~hajic/eacl03/submission.html) Send your submission to Ehud Reiter (ereiter(a)csd.abdn.ac.uk) IMPORTANT DATES Paper submissions: 7 January 2003 Notification of acceptance: 28 January 2003 Camera-ready copies due: 13 February 2003 Registration deadline: as ACL Workshop dates: 13-14 April 2003 REGISTRATION The registration fees include attendance of the workshop and a copy of workshop proceedings. Follow the registration instructions at the EACL site (http://www.conferences.hu/EACL03) and indicate that you would like to attend the NLG workshop. PARTICIPATION WITHOUT SUBMISSION People wishing to attend the workshop but not submitting papers should send a notification of attendance: a 1-2 page stating interest to participate, work done in NLG so far, and potential contributions / material for discussions about one of the topics. This information will help with the organisation of discussions and allow for an informal and highly interactive workshop. CONTACT INFO Notifications of attendance should be sent to Ehud Reiter (ereiter(a)csd.abdn.ac.uk)

1 0