- Haskell - Haskell.org

input of type String -> String
by S.D.Mechveliani 23 Jan '02

23 Jan '02

I asked recently whether reading from file can be made of type String -> String. I thought "If Haskell is non-functional, probably, this would be possible, and I would try this in certain small example. Otherwise, this is impossible, and I would be satisfied with readFile name >>= putStr " Thanks to people who explained me that the former case is impossible. So, Haskell is more functional than I thought. ----------------- Serge Mechveliani mechvel(a)botik.ru

1 0

Re: newtype pattern matching
by D. Tweed 23 Jan '02

23 Jan '02

(extra > because I initially sent this just Martin by mistake... oops) > On 22 Jan 2002, Martin [ISO-8859-1] Norb�ck wrote: > > > tis 2002-01-22 klockan 15.52 skrev Feuer: > > > Why is pattern matching on newtypes lazy? Does this add to efficiency > > > somehow? If not, it seems to be just another rule to keep straight. > > > > That's the difference between newtype and data. Newtypes are unboxed, so > > there is no constructor to match on. Pattern matching on newtypes is > > only a type-checker thing, the constructor doesn't exist. > > I don't know if this helps or confuses, but I think of it as newtype using > a `constructor' purely as a particular choice of syntax so that it looks > similar to the more general constructor syntax. But you could imagine a > different language design decision where instead of being written to look > like a constructor, for the declaration > > newtype M a = M [a] > > a new syntax ::: was introduced where e:::M means `expression e can only > be matched with the approriate type M a' (so for a concrete example, if > e :: [Int], then e ::: M means e can only be matched with newtype > M Int). Because of the similarity to the :: notation, which we're used to > seeing as `typechecker glue' that is only there to inform compilation, it > would be more intuitive that all the newtype stuff vanishes during > compilation. However, I think this syntax falls down in actually > constructing the raw values in the first place, e.g., > > f x = M (x++x) > > is easier to understand than > > f x = (x++x):::M > > so I can see why the constructor syntax was chosen.

1 0

String vs IO ()
by S.D.Mechveliani 23 Jan '02

23 Jan '02

I am sorry for, maybe, a silly question. f name = readFile name >>= putStr has the type String -> IO () And I need String -> String, so that (f name) is a string contained in the given file. I never learned such things in Haskell because they are rather non-functional. Thank you in advance for the help. ----------------- Serge Mechveliani mechvel(a)botik.ru

3 2

thanks for readFile
by S.D.Mechveliani 23 Jan '02

23 Jan '02

Thanks to people, who answered my question on readFile. It helped. ----------------- Serge Mechveliani mechvel(a)botik.ru

1 0

ideas for compiler project
by Hal Daume III 23 Jan '02

23 Jan '02

Hi All, I'm currently taking a class in compiler optimization for high performance computing (i.e., parallel architectures, including VLIW, FPGA, multimedia extension architectures, systems-on-a-chip, etc). It's the second of two graduate level compiler courses, and it purely project based. And the project is of our choosing. The professor has made some suggested projects, which I could do, but none of them are really FP specific. I'm curious if anyone has any ideas of a project I could do. I'm looking for something that's open, yet constrained, etc (standard semester-long-project-course stuff), hopefully having to do with optimizations specifically for FPLs, or at least ones that would benefit them. I'm open to all ideas... - 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

3 2

reading from file
by S.D.Mechveliani 22 Jan '02

22 Jan '02

Who would tell me, please, what is the simplest way to read a string from a file? Namely, what has one to set in place of `...' in the program main = putStr (...) to obtain instead of `...' a string contained in the file "foo.txt" ? Thank you in advance for the help. ----------------- Serge Mechveliani mechvel(a)botik.ru

2 1

ANNOUNCE: hmake-3.00
by Malcolm Wallace 22 Jan '02

22 Jan '02

hmake-3.00 ---------- We are pleased to announce the release of version 3.00 of 'hmake', the Haskell program compilation manager. http://www.cs.york.ac.uk/fp/hmake/ Features of hmake: * compiler independent * aware of .hi files in re-compilation analysis * respects cpp directives * supplies an optional Hugs-like interactive environment (hi) New features in 3.00: * improved detection and configuration of compilers * multiple compilers of the same type are now permitted simultaneously (e.g. ghc 4.08 + 5.02) * you can refer to compilers by simple name or absolute paths * a new separate tool 'hmake-config' manages hmakerc files * various Haskell preprocessors are now recognised and invoked (e.g. happy, hsc2hs, c2hs, greencard) if the corresponding file extension is found (.ly/.y, .hsc, .chs, .gc) * hooks for the forthcoming compiler-independent Haskell tracing system ('portable' Hat) are included Bug reports: Please send bug reports for 'hmake' to the mailing list nhc-bugs(a)haskell.org

2 2

SBLP'2002 First Call for Papers
by Carlos Camarao de Figueiredo 21 Jan '02

21 Jan '02

=============================================== SBLP'2002 VI Brazilian Symposium on Programming Languages http://www.inf.puc-rio.br/sblp Departamento de Informática PUC-Rio Rio de Janeiro, RJ, Brazil June 05-07, 2002 =============================================== First Call for Papers --------------------- The VI Brazilian Symposium on Programming Languages (SBLP'2002) will be held at Pontifícia Universidade Católica do Rio de Janeiro (PUC-Rio) in Rio de Janeiro, Brazil, on June 05-07, 2002. The symposium is sponsored by the Brazilian Computer Society (SBC) and aims to provide a forum where researchers, educators, and practitioners present and discuss the latest theoretical and practical work on programming languages. We invite authors to contribute to SBLP'2002 with the following kinds of submission: * Technical research papers introducing original research results on topics such as (but not limited to): - Programming language design and implementation - Formal semantics of programming languages - Domain-specific programming languages - Visual programming languages - Programming languages for mobile, WWW, and network computing - Script languages - Design and implementation of programming tools and environments - New programming models - Theoretical foundations of programming languages - Teaching programming languages * Experience reports on the use of programming languages, tools, and environments. The reports should clearly state the problems and difficulties identified on using those programming languages or technologies on projects, possibly giving solutions to those problems or hints to avoid them. * Tutorial proposals on subjects related to programming languages, APIs, tools, environments or theories. There will be also invited lectures, tutorials, panels, and working meetings to closely group together professionals interested on specific research topics. Important dates --------------- Deadline for submissions: February 28, 2002 Notification of acceptance: March 28, 2002 Camera-ready version: May 15, 2002 Conference chair ---------------- Edward Hermann Haeusler Departamento de Informática Pontifícia Universidade Católica do Rio de Janeiro Tel.: +55 (21) 3114-1500 R: 4345 email: hermann(a)inf.puc-rio.br Program Chair ------------- Carlos Camarão Departamento de Ciência da Computação Universidade Federal de Minas Gerais Tel: +55 (31) 3499 5889 email: camarao(a)dcc.ufmg.br Submission details ------------------- Contributions can be written in Portuguese, English or Spanish. Those written in English can be selected for publication elsewhere (probably Elsevier Electronic Notes in Theoretical Computer Science). All papers and experience reports will be published in the conference proceedings. Papers should have at most 14 pages and experience reports at most 8 pages. ---- Tutorials will be published in a separate proceedings. They should cover material of postgraduate level. The tutorial submission may be only a proposal, containing: - title - author names - motivation, describing the relevance of the subject in the area of programming languages - abstract - description of the presentation (optional) Tutorial proposals will be selected according to i) its technical quality and ii) expected relevance and interest from the community. The final tutorial should contain at most 30 pages. ---- Contributions should use the standard format of SBC (Brazilian Computer Society). They are available in: - LaTeX: http://www.sbc.org.br/templates/sbc-template-latex.zip - PDF/Adobe Acrobat: http://www.sbc.org.br/templates/sbc-template-latex.zip - Word: http://www.sbc.org.br/templates/sbc-template-dot.zip Use of LaTeX is preferred. Examples of the use of the SBC format can be found in these zip files. (You can also obtain them by visiting the site http://www.sbc.org.br and following the links *eventos* and, afterwards, *Informações úteis*.) For submission of contributions, fill out the required information at http://www.dcc.ufmg.br/~camarao/sblp/forms/authpaper_reg.html ======================================================================

1 0

ESSLLI 2002 Student Session
by Malvina Nissim 21 Jan '02

21 Jan '02

!!! Concerns all students in Logic, Linguistics and Computer Science !!! !!! Please circulate and post among students !!! We apologise if you receive this message more than once. ESSLLI-2002 STUDENT SESSION SECOND CALL FOR PAPERS August 5-16 2002, Trento, Italy Deadline: February 25th, 2002 www.iccs.informatics.ed.ac.uk/~malvi/esslli02 We are pleased to announce the Student Session of the 14th European Summer School in Logic, Language and Information (ESSLLI-2002) organised by the Centre for scientific and technological research (ITC-irst) in Trento and by the University of Trento, under the auspices of the European Association for Logic, Language and Information (FoLLI). ESSLLI-2002 will be held in Trento from August 5-16 2002. We invite submission of papers for presentation at the ESSLLI-2002 Student Session and for appearance in the proceedings. PURPOSE: This seventh ESSLLI Student Session will provide, like the other editions, an opportunity for ESSLLI participants who are students to present their own work in progress and get feedback from senior researchers and fellow-students. The ESSLLI Student Session encourages submissions from students at any level, from undergraduates (before completion of the Master Thesis) as well as postgraduates (before completion of the PhD degree). Papers co-authored by non-students will not be accepted. Papers may be accepted for full presentation (30 minutes including 10 minutes of discussion) or for a poster presentation. All the accepted papers will be published in the ESSLLI-2002 Student Session proceedings, which will be made available during the summer school. KLUWER BEST PAPER AWARD: As in previous years, the best paper will be selected by the programme committee and will be offered a prize of 600 euros by Kluwer Academic Publishers to be spent on books. REQUIREMENTS: The Student Session papers should describe original, unpublished work, completed or in progress that demonstrates insight, creativity, and promise. No previously published papers should be submitted. Note that the ESSLLI02 school will be focused on the three main interdisciplinary areas (Logic & Language, Logic & Computation, and Language & Computation), while the single areas have been dropped. Given the high interest shown over the years, the Student Session will keep two of the single areas, namely Logic and Language, welcoming thus submissions within the following topics: Logic, Language, Logic & Language, Logic & Computation, Language & Computation. FORMAT OF SUBMISSION: Student authors should submit an anonymous full paper headed by the paper title, not to exceed 7 pages of length exclusive of references and send a separate identification page (see below). Note that the length of the final version of the accepted papers will not be allowed to exceed 10 pages. Since reviewing will be blind, the body of the paper should omit author names and addresses. Furthermore, self-references that reveal the author's identity (e.g., "We previously showed (Smith, 1991)... ") should be avoided. It is possible to use instead references like "Smith (1991) previously showed...". For any submission, a plain ASCII text version of the identification page should be sent separately, using the following format: Title: title of the submission First author: firstname lastname Address: address of the first author ...... Last author: firstname lastname Address: address of the last author Short summary: abstract (5 lines) Subject area (one of): Logic | Language | Logic and Language | Logic and Computation | Language and Computation If necessary, the programme committee may reassign papers to a more appropriate subject area. The submission of the paper should be in one of the following formats: PostScript, PDF, RTF, or plain text. But note that, in case of acceptance, the final version of the paper has to be submitted in LaTeX format. Please, use A4 size pages, 11pt or 12pt fonts, and standard margins. Submissions outside the specified length and formatting requirements may be subject to rejection without review. The paper and separate identification page must be sent by e-mail to: malvi(a)cogsci.ed.ac.uk by FEBRUARY 25th 2002 ESSLLI-2002 INFORMATION: In order to present a paper at ESSLLI-2002 Student Session, at least one student author of each accepted paper has to register as a participant at ESSLLI-2002. The authors of accepted papers will be eligible for reduced registration fees. For all information concerning ESSLLI-2002, please consult the ESSLLI-2002 web site at www.esslli2002.it IMPORTANT DATES: Deadline for submission of papers: February 25, 2002. Authors notifications: April 22, 2002. Final version due: May 20, 2002. ESSLLI-2002 Student Session: August 5-16, 2002. PROGRAMME COMMITTEE: David Ahn, University of Rochester (Language and Computation) Carlos Areces, University of Amsterdam (Logic) Reinhard Blutner, University of Berlin (Language) Kees van Deemter, University of Brighton (Language and Computation) Paul Dekker, University of Amsterdam (Logic and Language) Juergen Dix, University of Manchester (Logic and Computation) Marta Garcia-Matos, University of Helsinki (Logic) Juan Heguiabehere, University of Amsterdam (Logic and Computation) Elsi Kaiser, University of Pennsylvania (Language) Malvina Nissim, University of Edinburgh (Chair) Rick Nouwen, University of Utrecht (Logic and Language) For any specific questions concerning ESSLLI-2002 Student Session, please, do not hesitate to contact me: Malvina Nissim ICCS, University of Edinburgh 2 Buccleuch Place, Edinburgh EH8 9LW, UK phone: +44 +(0)131 +650 4630 fax: +44 +(0)131 +650 6626 e-mail: malvi(a)cogsci.ed.ac.uk

1 0

H98 Report: semantics of pattern matching
by Ross Paterson 21 Jan '02

21 Jan '02

In section 3.17 Pattern Matching, there are some inconsistencies between the informal and formal semantics: (1) Section 3.17.2 Informal Semantics of Pattern Matching needs an extra rule (before rule 2): Matching _|_ against the pattern con pat, where con is a constructor defined by newtype, is equivalent to matching _|_ against the pattern pat. (2) Rule 3 "Matching _|_ against a refutable pattern always diverges" is untrue, because rules 4(b) and (c) (numeric literals and n+k patterns) are also applicable to _|_, and it is possible to define the Eq, Ord and Num classes so that pattern matching is non-strict: > data Foo = Foo > instance Eq Foo where _ == _ = True > instance Ord Foo where _ > _ = False > instance Show Foo > instance Num Foo > f :: Foo -> Int > f 0 = 20 > g :: Foo -> Int > g (n+1) = 20 -- Hugs incorrectly requires the Integral class so f undefined = g undefined = 20. Other definitions could be hyperstrict, so _|_/non-_|_ distinction isn't relevant. I'd suggest changing rule 3 to Matching _|_ against a pattern whose outermost component is a constructor defined by data always diverges. deleting rule 4 and promoting the subrules, removing "non-_|_" from (c) and changing "if x < k" to "otherwise". You might wish to say it diverges if x >= k does, but maybe that's too formal. (3) Section 3.17.3 Formal Semantics of Pattern Matching needs an extra equation: case _|_ of { K x1 ... xn -> e; _ -> e' } = _|_ where K is a data constructor of arity n (4) Equation (r) uses let, suggesting the possibility of polymorphism -- I'd suggest changing the rhs to if v >= k then case v-k of { x -> e } else e'

1 0